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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Nov 30, 2009, 15:59 UTC
Message-ID: <4B13EBD6.5060608@drmicha.warpmail.net>
In-Reply-To: <cover.1259524136.git.brlink@debian.org>

Bernhard R. Link venit, vidit, dixit 30.11.2009 15:43: [...]

Ok, I couldn't resist looking at your examples. Actually, before anything else: Thanking for describing *what* you want to achieve, not only how.

Show 18 quoted lines

> Example 1:
> 
> Let's assume you maintain such a regularily-rebased branch that you
> want to be able to publish (or pull from other repositories for example
> on your laptop):
> 
> o=m=o=o=master
>    \
>     a=b=c=d=e=feature
> 
> with this patch you can do "git rebase -eqt master" and get:
> 
>               a'=b'=c'=d'=e'=feature'=eqt
>              /                       /
> o=m=o=o=master--------              /
>    \                  \            /
>     a=b=c=d=e=feature--merge-------
>

git checkout -b featureprime feature git rebase master git merge feature # should be trivial git branch -M featureprime feature

Show 40 quoted lines

> i.e: the new feature branch has both histories:
>   - "feature'" where everything is cleanly rebased and in a form where
>                format-patch is suitable to send it upstream
>   - "merge" which is both a descendant from feature (so one can see what
>     changed since that time and can just pull when one had had cloned feature)
> 
> Example 2:
> 
> Let's assume you have a feature branch like
> 
> o=master
>    \
>     a=b=c=d=e=f
> 
> Assume you just commited "f" which fixes a bug introduced by "b".
> Now you of course do not want to send it that way upstream (as it will
> make reviewing harder, may force people bisecting to skip some versions
> every time they hit this region and so on), so you want to
> bisect -i and squash "f" into "b".
> 
> o=master
>    \
>     a=b+f=c'=d'=e'
> 
> But if you had already cloned at state "d" to your laptop (or made a backup
> of that branch at some server, or published it for use of some collegues)
> it will not be a fast-forward, so you have to be very carefull to not
> accidentially lose a commit that is already there.
> 
> So with this patches you can do "git rebase -i --eqt" and squash f into b
> and get:
> 
> o=master
>    \
>     a=b=c=d=e=f---
>      \            \
>       b+f=c'=d'=e'=eqt
> 
> which means that you can just pull from your laptop and get the new head
> as fast-forward, but still have a proper history ready for submitting.

If that side branch is named "feature": git checkout -b fixup feature git rebase -i a # squash f into b; creates b+f c# d' e' git merge feature # should be trivial git branch -M fixup feature

You can also go crazy with rebase --onto here, or use cherry-pick repeatedly.

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.

Cheers, Michael