On 2012-05-18 19:05:05 +0200, Diego Biurrun wrote:
> ---
> doc/git-howto.texi | 52
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 52 insertions(+), 0 deletions(-)
>
> diff --git a/doc/git-howto.texi b/doc/git-howto.texi
> index 4d3e235..b34fae2 100644
> --- a/doc/git-howto.texi
> +++ b/doc/git-howto.texi
> @@ -346,6 +346,58 @@ 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.
I honestly think the wording and the checklist is way too strict for
most commits. Strictly following it for every commit is nonsense and
I'd guess nobody will do it.
> +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 commands:
> +
> +@itemize
> +@item @command{git cherry -v}
> +
> +to make sure that only the commits you want to push are pending.
> +
> +@item @command{git log}
> +
> +to check that the log messages of the commits are correct and descriptive
> +and contain no cruft from @command{git am}.
why not combining these two with @command{git log origin/master..}?
> +@item @command{git log -p}
> +
> +to doublecheck that the commits you want to push really only contain the
> +changes they are supposed to contain.
--stat might be helpful too, add the same 'origin/master..', mention
that it coud be combined with the above.
> +
> +@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, so updating it once per day or so
> +is sufficient. Now execute
Updating once per day is always enough since put new samples at 24h in
place before pushing the
> +@itemize
> +@item @command{make distclean}
When is a make clean not enough?
> +@item @command{./configure}
without distclean this could be a simple make config which would handle
out of source tree builds and other required configure options just
fine.
> +@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 tests necessary to convince
> +yourself the changes you are about to push actually work as expected.
you fail to mention that every commit is expected to pass make check
> +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.
git push reports for every commit if it could match a patch. Updating
not revisions of the patch on patchwork is also a good idea if not
done earlier.
Janne
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
