Re: [QUESTION] Pushing patches.

[Stefano Lattarini]

At Thursday 15 July 2010, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Wed, Jul 14, 2010 at 03:51:05PM CEST:
> > Independently from the fact that you give or not your OK to this
> > particular patch, I'd like to know if the following procedure is
> > correct for the pushing of simple patches which should go into
> 
> > both maint and master:
> Yes, with the following minor changes:
> 
> 0. Install and configure the git-merge-changelog program (get it
> from gnulib, look at its source code header for instructions how
> to use it).
I forgot to mention that I've already done that, with the entry in
~/.gitconfig being:
  
  [merge "merge-changelog"]
    name = GNU-style ChangeLog merge driver
    driver = git-merge-changelog %O %A %B

However, there is a problem w.r.t. the Automake policy of keeping 
multiple ChangeLog entries with same author and date lumped togheter. 
In fact, git-merge-changelog seems to separate them when rebasing
(see the attached script for an example).  IMVHO the best thing to do
here is to change the Automake ChangeLog policy, using e.g.

  2000-01-01  Foo Bar  <address@hidden>

        Add foo

  2000-01-01  Foo Bar  <address@hidden>

        Add bar

instead of:
  
  2000-01-01  Foo Bar  <address@hidden>

        Add foo

        Add bar

WDYT?


> >  1. Checkout the "maint" branch on my local repos:
> >      $ git co maint
> 
> If "co" is a short-hand command alias for checkout, then yes.
Oops, I'm so used to this alias that I've forgot it's not a stock git 
command...  Sorry about that.

> 
> >  2. Apply the patch(es) with "git am":
> >      $ git am 0*.patch
> 
> Use "git am -3" for a better user experience in the presence of
> not-quite-matching changes.
Thanks for the tip, will do.

> 
> >  2a. (Run required tests, if any)
> >  
> >  3. Merge maint into master:
> >      $ git co master && git merge maint
> 
> I'd first merge it into branch-1.11:
>   git checkout branch-1.11
>   git merge maint
> 
> then into master.
OK, will do that.

> 
> BTW, my informal way of merging has been to merge maint
> without --log but merge feature branches with --log; rationale is
> that feature branches may have patches which are not quite new in
> relation to other patches, and thus 'git log' may not have them
> show up early in the list.
Thanks for the explanation.  This would IMO make a very nice addition 
to HACKING, BTW.

> 
> >  3a. (Run required tests, if any)
> >  
> >  4. Push the maint and master branches:
> >    $ push --dry-run origin master maint # and if all seems ok...
> >    $ push origin master maint
> 
> git push --dry-run origin master maint branch-1.11
OK.

And since we are at it, I have another question.  If I have N (> 1) 
unrelated but simple patches to apply to maint, it's OK to apply
all of them sequentially, and only then do the merges to master and 
branch-1.11?

Thanks,
   Stefano

foo.sh
Description: application/shellscript