On Mon, Oct 27, 2008 at 2:52 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > On Mon, 27 Oct 2008, Arne Babenhauserheide wrote: >> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski: >> > >> > I agree, and I think it is at least partially because of Git having >> > cleaner design, even if you have to understand more terms at first. >> >> What do you mean by "cleaner design"? > > Clean _underlying_ design. Git has very nice underlying model of graph > (DAG) of commits (revisions), and branches and tags as pointers to this > graph. Git and Mercurial are very close from that point of view. Mercurial explicitely disallow octopus merges (and we don't think there's a good reason to allow them, although I agree with Linus, they look very nice in gitk ;) ). And we don't have "branches as pointer" in core, but the bookmark extension does that. Appart from that I think the underlying format are interchangeable, someone could use the git format with the hg ui, or use revlogs (the basic format of mercurial) like packs. The only special thing about revlogs is the linkrev stuff, it's a pointer to the first revision that introduced an object, so we can easily find what to send in our network protocol (we don't have to read the manifest, ie the "tree" of objects"). linkrev can be useful to speedup "hg log" too. > I have read description of Mercurial's repository format, and it is not > very clear in my opinion. File changesets, bound using manifest, bound > using changerev / changelog. > just do a s/// with the git terminology: filelog -> blob manifest -> tree changelog -> commit object regards, Benoit -- 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
