On Tue, 3 Jun 2008, Jakub Narebski wrote: > > I think that octopus merge (merge with more than two parents/legs) is > feature which is unique to git (isn't it?). Do you remember perhaps > why it was introduced? Well, mainly because the data structures supported the notion naturally. Once you have 0, 1 or 2 parents, the logical progression is "many". > What does it give, beside making it difficult > to convert git repositories using this feature to others SCMs 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. As to how useful it is.. We don't have a lot of them in the kernel, but I do have to say that the ones we have generally tend to make perfect sense. To see just octopus merges, do git rev-list --parents HEAD | grep '.* .* .* ' | git diff-tree --stdin --pretty --always -S | less -S but a couple of them are actually fake (same parent listed twice), due to a confluence of (a) historically bad "git merge" semantics and (b) a bug that made it not notice. In fact, that bug seems to have re-appeared, now that I look at it! Junio: see kernel commits a733a5da9 and 52b097fff89, done as lately as February of this year. We shouldn't allow that kind of thing, and in git we have commits b389237ae and 6ea23343ce that were both about those kinds of mis-uses. That said, most of those octopus merges look fine and actually give a nicer view of history. Of course, Len has been known to over-do it a bit ;) Linus -- 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
