git, merging patches

[Bruno Haible]

Hi Paul,

> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,5 +1,27 @@
> +2011-07-17  Paul Eggert  <address@hidden>
> +
> +     pthread_sigmask: assume POSIX if not using threadlib
> +     This differs from the previous patch, in that it does not distinguish
> +     from gl_THREADLIB being avoided, and it not being used.
> +     * gnulib-tool: Undo previous change; no longer needed.
> +     * m4/pthread_sigmask.m4 (gl_FUNC_PTHREAD_SIGMASK):
> +     Assume POSIX if gl_THREADLIB is defined, not if threadlib is avoided.
> +     Spell gl_THREADLIB in a funny way so that aclocal doesn't see it.
> +     * modules/pthread_sigmask (Depends-on): Remove threadlib,
> +     since the module now works without threadlib.
> +
>  2011-07-16  Paul Eggert  <address@hidden>
>  
> +     pthread_sigmask: assume POSIX if --avoid=threadlib
> +     * m4/pthread_sigmask.m4 (gl_FUNC_PTHREAD_SIGMASK): If threadlib is
> +     avoided, do not require it.  Instead, assume the application has
> +     already arranged for POSIX threads, if it is multithreaded.
> +     GNU Emacs can use this.
> +
> +     gnulib-tool: Define gl_AVOID_MODULE_x given --avoid=x.
> +     * gnulib-tool (func_dest_tmpfilename):
> +     Define gl_AVOID_MODULE_x for each avoided module x.
> +

Regarding git commits, I'm in favour of the general rule "one change
per commit" - "independent changes in independent commits".

When it comes to a patch series like this one, however, where
  - the original author is reworking how own patches,
  - as a result of discussions, part of the changes are reverted,
it is more appropriate to merge patches together and remove reverted
patches from the history and the ChangeLog.

Once we have convinced ourselves that a certain patch was a dead end,
and reverted it, it is better omitted. Otherwise reviewing the resulting
patch gets more and more cumbersome. Whereas ideally, the more someone
works on a patch, the easier it should be to review and approve it.

With 'git' you can do that. It does take two minutes or so, to think about
which parts you will merge together, running "git commit --amend" or
"git rebase -i origin/master", and updating the ChangeLog, but it is a win for
those who will review the changes and for future maintenance.

It takes about 1 hour to learn "git commit --amend" [1] and "git rebase -i".
I prefer the explanation in [2] to the one in [3][4]. Be sure to make
a backup copy of your gnulib checkout before starting the experiments.

Bruno

[1] 
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#fixing-mistakes
[2] http://www.vogella.de/articles/Git/article.html#rebase_commits
[3] 
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#cleaning-up-history
[4] http://www-cs-students.stanford.edu/~blynn/gitmagic/ch04.html
-- 
In memoriam Jane Haining <http://en.wikipedia.org/wiki/Jane_Haining> 
<http://www.shoah.dk/Courage/Haining.htm>