]> git.sesse.net Git - ffmpeg/blobdiff - doc/git-howto.texi
mpjpeg: Check stream allocation
[ffmpeg] / doc / git-howto.texi
index b01981e05e61b5f91841af9574bb3056b692528a..5a8e2a38231563a42308da9cbf058a20478da328 100644 (file)
@@ -65,6 +65,14 @@ git clone git@@git.libav.org:libav.git <target>
 This will put the Libav 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,
+otherwise you may experience spurious compilation failures. One way to
+achieve this is to run
+
+@example
+git config --global core.autocrlf false
+@end example
+
 
 @section Updating the source tree to the latest revision
 
@@ -250,6 +258,32 @@ git commit
 @end example
 
 
+@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.
+
+@section Personal Git installation
+
+Add the following to your @file{~/.gitconfig} to help @command{git send-email}
+and @command{git format-patch} detect renames:
+
+@example
+[diff]
+        renames = copy
+@end example
+
+@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}:
+
+@example
+[sendemail]
+        to = libav-devel@@libav.org
+@end example
+
 @chapter Libav specific
 
 @section Reverting broken commits
@@ -338,6 +372,68 @@ git checkout -b svn_23456 $SHA1
 
 where @var{$SHA1} is the commit hash from the @command{git log} output.
 
+
+@chapter pre-push checklist
+
+Once you have a set of commits that you feel are ready for pushing,
+work through the following checklist to doublecheck everything is in
+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:
+
+@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
+
+@itemize
+@item @command{make distclean}
+@item @command{/path/to/libav/configure}
+@item @command{make check}
+@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.
+
+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 commits
+to push, run the test suite on every single commit.
+
+Give other developers a reasonable amount of time to look at and review
+patches before you push them. Not everybody is online 24/7, but may wish
+to look at and comment on a patch nonetheless. The time you leave depends
+on the urgency and complexity of the patch. Use your common sense to pick
+a timeframe that allows everybody that you think may wish to comment
+and/or should comment on the change an opportunity to see it.
+
+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.
+
+
 @chapter Server Issues
 
 Contact the project admins @email{git@@libav.org} if you have technical