Jan Hudec wrote: > Actually bzr used to have slightly different numbering scheme not long > ago. There was a revision-history in each branch listing the revisions > in order in which they were commited or merged in. Some time ago it was > changed to numbering along the leftmost parent, which was, IIRC, deemed > simpler and a little more logical. But in the light of these arguments, > maybe the former system was better -- it was more dependent on the > actual location, but on the other hand it allowed (or could allow -- > IIRC there was some problem with it) to fast-forward merge while > _locally_ keeping the meaning of old revision numbers. In fact, the > revision-history used to be almost exactly the same as git reflog, > except it only stored the revids, not the times. Which is very fine if you don't modify the history (amending commits, rewinding history to earlier point, rebasing the branch, merging branch in and starting it anew aka. dovetail approach if I remember correctly), and if you are not concerned with performance when fetching larger number of commits into branch (as you have to assign number to them). Which was perhaps why bzr changed from revnolog to leftmost/first parent as a way to keep branch-as-path/assing revision numbers to revisions. Which has it's own disadvantages as enumerated multiple times here on the list. -- Jakub Narebski Poland - 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