Re: equal-tree-merges as way to make rebases fast-forward-able
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 1, 2009, 00:25 UTC
- Message-ID
- <7vtywba6bj.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20091130185540.GA5764@pcpool00.mathematik.uni-freiburg.de>
"Bernhard R. Link" <brlink@debian.org> writes:
Show 17 quoted lines
>> 3-------. >> / \ >> 0---2---W---B >> \ / >> 1-------Z >> >> That is, Z and W records the interdifff between 1 to 3 and 2 to 3 >> respectively, and B is a same-tree merge of 3, W and Z. > > I think changing it to get this would be easy (though only in the case > where the very last commit was such an equal tree merge), but I do not > think it would be actually better: > > - it is no longer possible to see the history of changes by just walking > right on every equal-tree-merge. > - commit a no longer exists. If some downstream already has > cloned/pulled, no fast-forward is possible any more.
Oh, I wasn't suggesting you to change it to use an octopus. I however did want to know if you considered pros-and-cons with such an alternative (there perhaps are other approaches as well), and I agree recording one iteration at a time like you do is better.