[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fake merges (was: [PATCHES] Bootstrap: Allow user overriding of $AUTOCON
From: |
Ralf Wildenhues |
Subject: |
fake merges (was: [PATCHES] Bootstrap: Allow user overriding of $AUTOCONF and $PERL.) |
Date: |
Sun, 8 Aug 2010 13:19:30 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
* Stefano Lattarini wrote on Sun, Aug 08, 2010 at 01:13:07PM CEST:
> At Sunday 08 August 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Sun, Aug 08, 2010 at 12:53:21PM CEST:
> > > At Sunday 08 August 2010, Ralf Wildenhues wrote:
> > > > Also, regenerating the tree with Autoconf 2.67 and committing
> > > > that separately is preapproved for maint.
> > >
> > > Couldn't this cause problems when later merging to master? If
> > > yes, how would those be better solved?
> >
> > This is solved most easily by having one commit in maint that
> > regenerates the tree, and merging that in the active branches.
> > You may want to do a fake merge in this case to force a correctly
> > created configure script for the branches ...
> Pardon my ignorance, but what do you mean by "a fake merge"?
When you merge a branch A into B, then it can happen that git sees no
conflicts, but in reality things break anyway. This can easily happen
when, say, A renames a variable, B adds new code using the old variable.
Then you need to fix up the code after the merge. You can 'git commit
--amend' the fixup to the merge. I think this is what is called a fake
merge.
In the case of regenerating with newer Autoconf, I just ran bootstrap on
maint with 2.67, merged that into branch-1.11. That caused a conflict,
but even if it hadn't, I would've rerun bootstrap and commit --amend'ed
so that files are correct for the branch. Same for master.
I just did that and pushed.
Cheers,
Ralf