Jakub Narebski <jnareb@xxxxxxxxx> writes: > On Tue, 3 June 2008, Junio C Hamano wrote: >> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
