On Tue, 17 Oct 2006, Aaron Bentley wrote: > > > > Excuse me? What does that "throws away your local commit ordering" mean? > > Say this is the ordering in branch A: > > a > | > b > | > c > > Say this is the ordering in branch B: > > a > | > b > |\ > d c > |/ > e > > When A pulls B, it gets the same ordering as B has. If B did not have e > and c, the pull would fail. Sure. But that doesn't throw away any local commit ordering. The original order (a->b->c) is still very much there. The fact that there was a branch off 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't take away anything from the original local commit ordering. > > So generating an extra "merge" commit would be actively wrong, and adds > > "history" that is not history at all. > > It's not a tree change, but it records the fact that one branch merged > the other. But that's a totally specious "record". It has no meaning in a distributed SCM. There is absolutely zero semantic information in it. The fact that you _locally_ want to remember where you were is a total non-issue for a true distributed system. You shouldn't force everybody else to see your local view - since it has no relevance to them, and doesn't add any information. > Maybe not in Git. I don't think there is any in bzr either. Can you explain? In other words, the empty merge is totally semantically empty even in the bazaar world. Why does it exist? 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