diff options
Diffstat (limited to 'doc/git-howto.texi')
| -rw-r--r-- | doc/git-howto.texi | 84 |
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. |
