summaryrefslogtreecommitdiffstats
path: root/doc/git-howto.texi
diff options
context:
space:
mode:
Diffstat (limited to 'doc/git-howto.texi')
-rw-r--r--doc/git-howto.texi84
1 files changed, 33 insertions, 51 deletions
diff --git a/doc/git-howto.texi b/doc/git-howto.texi
index 5114115..44e1cc6 100644
--- a/doc/git-howto.texi
+++ b/doc/git-howto.texi
@@ -1,9 +1,9 @@
\input texinfo @c -*- texinfo -*-
-@settitle Using git to develop Libav
+@settitle Using git to develop FFmpeg
@titlepage
-@center @titlefont{Using git to develop Libav}
+@center @titlefont{Using git to develop FFmpeg}
@end titlepage
@top
@@ -39,7 +39,7 @@ For more information about the Git project, visit the
Consult these resources whenever you have problems, they are quite exhaustive.
-What follows now is a basic introduction to Git and some Libav-specific
+What follows now is a basic introduction to Git and some FFmpeg-specific
guidelines to ease the contribution to the project
@chapter Basics Usage
@@ -53,16 +53,16 @@ Most distribution and operating system provide a package for it.
@section Cloning the source tree
@example
-git clone git://git.libav.org/libav.git <target>
+git clone git://source.ffmpeg.org/ffmpeg <target>
@end example
-This will put the Libav sources into the directory @var{<target>}.
+This will put the FFmpeg sources into the directory @var{<target>}.
@example
-git clone git@@git.libav.org:libav.git <target>
+git clone git@@source.ffmpeg.org:ffmpeg <target>
@end example
-This will put the Libav sources into the directory @var{<target>} and let
+This will put the FFmpeg sources into the directory @var{<target>} and let
you push back your changes to the remote repository.
Make sure that you do not have Windows line endings in your checkouts,
@@ -85,7 +85,7 @@ can be remote. By default the master branch tracks the branch master in
the remote origin.
@float IMPORTANT
-Since merge commits are forbidden @command{--rebase} (see below) is recommended.
+@command{--rebase} (see below) is recommended.
@end float
@section Rebasing your local branches
@@ -96,7 +96,7 @@ git pull --rebase
fetches the changes from the main repository and replays your local commits
over it. This is required to keep all your local changes at the top of
-Libav's master tree. The master tree will reject pushes with merge commits.
+FFmpeg's master tree. The master tree will reject pushes with merge commits.
@section Adding/removing files/directories
@@ -127,7 +127,7 @@ git log <filename(s)>
@end example
You may also use the graphical tools like gitview or gitk or the web
-interface available at http://git.libav.org/
+interface available at http://source.ffmpeg.org/
@section Checking source tree status
@@ -261,7 +261,7 @@ git commit
@chapter Git configuration
In order to simplify a few workflows, it is advisable to configure both
-your personal Git installation and your local Libav repository.
+your personal Git installation and your local FFmpeg repository.
@section Personal Git installation
@@ -276,15 +276,15 @@ and @command{git format-patch} detect renames:
@section Repository configuration
In order to have @command{git send-email} automatically send patches
-to the libav-devel mailing list, add the following stanza
-to @file{/path/to/libav/repository/.git/config}:
+to the ffmpeg-devel mailing list, add the following stanza
+to @file{/path/to/ffmpeg/repository/.git/config}:
@example
[sendemail]
- to = libav-devel@@libav.org
+ to = ffmpeg-devel@@ffmpeg.org
@end example
-@chapter Libav specific
+@chapter FFmpeg specific
@section Reverting broken commits
@@ -381,53 +381,35 @@ proper order. This list tries to be exhaustive. In case you are just
pushing a typo in a comment, some of the steps may be unnecessary.
Apply your common sense, but if in doubt, err on the side of caution.
-First make sure your Git repository is on a branch that is a direct
-descendant of the Libav master branch, which is the only one from which
-pushing to Libav is possible. Then run the following command:
+First, make sure that the commits and branches you are going to push
+match what you want pushed and that nothing is missing, extraneous or
+wrong. You can see what will be pushed by running the git push command
+with --dry-run first. And then inspecting the commits listed with
+@command{git log -p 1234567..987654}. The @command{git status} command
+may help in finding local changes that have been forgotten to be added.
-@itemize
-@item @command{git log --patch --stat origin/master..}
-
-to make sure that only the commits you want to push are pending, that
-the log messages of the commits are correct and descriptive and contain
-no cruft from @command{git am} and to doublecheck that the commits you
-want to push really only contain the changes they are supposed to contain.
-
-@item @command{git status}
-
-to ensure no local changes still need to be committed and that no local
-changes may have thrown off the results of your testing.
-@end itemize
-
-Next let the code pass through a full run of our testsuite. Before you do,
-the command @command{make fate-rsync} will update the test samples. Changes
-to the samples set are not very common and commits depending on samples
-changes are delayed for at least 24 hours to allow the new samples to
-propagate, so updating it once per day is sufficient. Now execute
+Next let the code pass through a full run of our testsuite.
@itemize
@item @command{make distclean}
-@item @command{/path/to/libav/configure}
+@item @command{/path/to/ffmpeg/configure}
@item @command{make check}
+@item if fate fails due to missing samples run @command{make fate-rsync} and retry
@end itemize
-While the test suite covers a wide range of possible problems, it is not
-a panacea. Do not hesitate to perform any other tests necessary to convince
-yourself that the changes you are about to push actually work as expected.
+Make sure all your changes have been checked before pushing them, the
+testsuite only checks against regressions and that only to some extend. It does
+obviously not check newly added features/code to be working unless you have
+added a test for that (which is recommended).
Also note that every single commit should pass the test suite, not just
-the result of a series of patches. So if you have a series of related
-commits, run the test suite on every single commit.
-
-Finally, after pushing, mark all patches as committed on
-@url{http://patches.libav.org/,patchwork}.
-Sometimes this is not automatically done when a patch has been
-slightly modified from the version on the mailing list.
-Also update previous incarnations of the patches you push so that
-patchwork is not cluttered with cruft.
+the result of a series of patches.
+Once everything passed, push the changes to your public ffmpeg clone and post a
+merge request to ffmpeg-devel. You can also push them directly but this is not
+recommended.
@chapter Server Issues
-Contact the project admins @email{git@@libav.org} if you have technical
+Contact the project admins @email{root@@ffmpeg.org} if you have technical
problems with the GIT server.
OpenPOWER on IntegriCloud