-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakub Narebski wrote: > Aaron Bentley wrote: >> Linus Torvalds wrote: >>> 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. >> After the pull, it's no longer the mainline ordering for the branch. c >> is represented a revision that was merged into the branch, while d is >> represented as a commit on the mainline of the branch. > > Well, that is another example while generation number is/can be global, > any numbering of branches must be local-only. No. The numbering always follows the leftmost parent. So each revision has a permanent (but non-unique) number. > That doesn't matter... It has significant UI impact. >> and the revision numbers can change. > > ...but that means that revision numers are totally, absolutely useless. > Unless by some miracle of engineering, or adding namespace, they can be > made unchangeable. No, because no one pulls unless they're trying to maintain a mirror of the other branch, or else they decide to throw their local history away. >> Nobody is forced to use your local view. > > But if you record "fast-forward merge", you force all people pulling > from your repository to have this purely local and without any significant > information "I have fetched then" marker. Even if I agreed that the revision was meaningless, the cost of such a revision is miniscule. >>> In other words, the empty merge is totally semantically empty even in the >>> bazaar world. Why does it exist? >> It exists because it is useful. Because it makes the behavior of bzr >> merge uniform. Because in some workflows, commits show that a person >> has signed off on a change. > > Signing off the fact of fetching changes? For true merge you are signing > off the fact that there were no conflicts, or you sign off your conflict > resolution. You sign off on the contents of the revision you fetched. You say "I have reviewed this revision, and approved it." >> It's not something special-- it's just another commit, like regular >> commits, and merge commits. It would be harder to forbid than it is to >> permit. > > Actualy the check is very easy. Agreed. It's just that not checking is easier still. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNXzD0F+nu1YWqI0RAiGvAJsEbPNNlqZ7QCH7EE39YABqEm/BtwCaAxIo NHqG4NVZpvymTUlCLYyCqKM= =YUdC -----END PGP SIGNATURE----- - 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