Jakub Narebski <jnareb@gmail.com> writes:

quoted text
> On Tue, 3 June 2008, Junio C Hamano wrote:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> 
>>> Actually, it's trivial to convert to other SCM's, although I guess the 
>>> conversion tools haven't really tried. You can always turn it into a 
>>> series of multiple merges. Yes, you lose information, but it's not like 
>>> you lose a huge amount.
>> 
>> One thing to worry about is what tree object you would give to each of
>> these "artificially split" merge commits, though.
>
> There shouldn't be, I think, a problem if octopus merge was done using
> 'octopus' merge strategy,...

You are sort-of right.

An octopus capable history may say "This is a merge between commit A, B
and C".  A trivial/naïve conversion to a foreign history that can only
express two-parent merges must say "This X is a merge between commit A and
B", followed by "This is a merge between X and C".  X, cross between A and
B, _should_ be a merge that can be reliably and trivially recreated.  This
actually is the reason why "my" octopus strategy implementation refuses to
record anything nontrivial.

But that's not something you should assume, as you can commit anything
with commit-tree.  Some people might even be using sg/merge-options series
parked in 'pu' that makes what the recorded parenthood and what the used
parents different even more.

A cleverer Octopus reimplementation might even try different orders in
which it performs its internal pairwise merges, and at that point the
order of recorded parents won't have any resemblance to the order their
trees were used in the internal pairwise merges.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html