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

From: Bernhard R. Link <brlink@debian.org>
Date: Nov 30, 2009, 16:22 UTC
Message-ID: <20091130162229.GA3792@pcpool00.mathematik.uni-freiburg.de>
In-Reply-To: <hf0oh0$elj$1@ger.gmane.org>

* Paolo Bonzini <bonzini@gnu.org> [091130 16:32]:

Show 6 quoted lines

> On 11/30/2009 03:43 PM, Bernhard R. Link wrote:
>> The itch this idea is supposed to scratch is the problem that a rebase
>> or a amended commit is no longer a fast-forward, so cannot be easily
>> pulled.
>
> How does this compare with topgit?

It's not easily compareable as having different aims, but I think there are some use-cases where this allows native usage of git where previously the best bet was topgit.

Assume for example you want to maintain a set of patches of some upstream, which you want to have in some form relative to upstream and in patches easily reviewable and pickable by other people.

You could do that with topgit by making each change a topgit branch. But to clone that repository then you would need topgit to get all the information and cherry picking one of your changes (that perhaps grow with the time, was adapted to new upstreams and had bugs fixed) needs telling topgit to combine the changes of that branch and use that instead of a simple cherry pick.

With this equal-tree-marker you can just do a git rebase --eqt or git rebase -i --eqt and both have a history with your changes as single commits which are easy to look at (and you can just pushing head^1 somewhere for upstream to pull from) while still having all the history in your git archive so someone else can look what actually happened or just clone your current head and repeatenly pull from it.

Hochachtungsvoll,
	Bernhard R. Link