[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [QUESTION] Pushing patches.
From: |
Stefano Lattarini |
Subject: |
Re: [QUESTION] Pushing patches. |
Date: |
Thu, 15 Jul 2010 12:26:57 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
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
- [PATCH + QUESTION] Improve and extend tests `man*.test'., Stefano Lattarini, 2010/07/12
- Re: [PATCH + QUESTION] Improve and extend tests `man*.test'., Ralf Wildenhues, 2010/07/13
- Re: [PATCH + QUESTION] Improve and extend tests `man*.test'., Stefano Lattarini, 2010/07/13
- [QUESTION] Pushing patches., Stefano Lattarini, 2010/07/14
- Re: [QUESTION] Pushing patches., Ralf Wildenhues, 2010/07/15
- Re: [QUESTION] Pushing patches.,
Stefano Lattarini <=
- Re: [QUESTION] Pushing patches., Ralf Wildenhues, 2010/07/15
- Re: [QUESTION] Pushing patches., Stefano Lattarini, 2010/07/15
- Re: [QUESTION] Pushing patches., Ralf Wildenhues, 2010/07/15
- Re: [QUESTION] Pushing patches., Stefano Lattarini, 2010/07/15