* Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> [091130 17:00]:
> 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
> [...]
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html