On Mon, 23 Oct 2006, Jakub Narebski wrote: > > By the way, I wonder if accidentally identical revisions > (see example for accidental clean merge on revctrl.org) > would get the same revision id in bzr. In git they would. git can have no "accidentally identical revisions". They'd have to be purposefully done, but yes, they'd obviously (on purpose) get the same revision name if that's the case. You may think of tree (not commit) identity, where git on purpose names trees the same regardless of how you got to them. So on a _tree_ level, you are always supposed to get the same result regardless of how you import things (ie two people importing the same tar-ball should always get exactly the same tree ID). But the actual commit names are identical only if the same people are claimed to have authored (and committed) them at the same time - so it's definitely not "accidental" if the commits are called the same: they really _are_ the same. Btw, I think you misunderstand the term "accidental clean merge". It means that two identical changes on two branches will merge without conflicts being reported. A merge algorithm that doesn't do "accidental clean merge" is totally broken. The accidental clean merge is a usability requirement for pretty much anything - you often have two branches doing the same thing (possibly for different reasons - two people independently found the same bug that showed itself in two different ways - so they may even think that they are fixing different issues, and may have written totally different changelogs to explain the bug, but the solution is identical and should obviously merge cleanly). So "accidental clean merge" may _sound_ like something bad, but it's actually a seriously good property (it's really just a special case of "convergence" - again, that's a good thing). 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