Re: equal-tree-merges as way to make rebases fast-forward-able

From: Bernhard R. Link <brlink@debian.org>
Date: Nov 30, 2009, 16:54 UTC
Message-ID: <20091130165437.GB3792@pcpool00.mathematik.uni-freiburg.de>
In-Reply-To: <4B13EBD6.5060608@drmicha.warpmail.net>

* Michael J Gruber <git@drmicha.warpmail.net> [091130 17:00]:

Show 12 quoted lines

> Bernhard R. Link venit, vidit, dixit 30.11.2009 15:43:
> > o=m=o=o=master
> >    \
> >     a=b=c=d=e=feature
> >
> > with this patch you can do "git rebase -eqt master" and get:
> >
>
> git checkout -b featureprime feature
> git rebase master
> git merge feature # should be trivial
> git branch -M featureprime feature

> [...]

Show 5 quoted lines

> Note that I always use a temporary branch for rewriting, before renaming
> it to the proper branch name. I haven't checked, but I assume the
> "first-parents" are the way you want them (you want log --first-parent
> --no-merges to show the rewritten commits, right?); otherwise you would
> have to do the merges the other way round.

My problem with that is that --first-parent-only makes no difference between this and other merges.

Assume the example2

o=master
   \
    a=b=c=d=e=f---
     \            \
      b+f=c'=d'=e'=eqt

would continue with some paralel commits and a merge:

o=master
   \
    a=b=c=d=e=f---       y
     \            \     / \
      b+f=c'=d'=e'=eqt-x   m
                        \ /
                         z

now if you rebase that tree (or want to send it with format-patch), you either get the old commits multiple times in format-patch (and possibly causing already resolved conflicts when doing the am step in rebase), or you use --first-parent-only and might miss z.

Thus the idea to have some way to destinguish this merge from a normal merge and thus the extra pseudo-merge in example 1 to get the following merge to merge things with equal tree.

Hochachtungsvoll,
	Bernhard R. Link

-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
	Niklaus Wirth