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

["Bernhard R. Link" <brlink@debian.org>]

* Paolo Bonzini <bonzini@gnu.org> [091130 16:32]:
> 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