Re: Hg sure is weird!

Michael Sperber writes: MQ destroys that history, except to the extent that it's in the ChangeLog, right? Well, first of all, Mercurial merge artifacts and rebase are quite independent of each other. Merges are necessary, and they will show up in git and in any other VCS. The Mercurial artifacts truly are artifacts. They occur because of a poor algorithm choice where Mercurial iterates over the revision array, which is an arbitrary total order compatible with the revision DAG, rather than using that DAG. Anyway, it looks like most of what I want can be accomplished by using "hg log --follow-first" and using explicit revisions for "hg diff" rather than hoping that revno-- has any reliable relation to revno. Still, it's a major wart that sequence numbers are exposed at all. As for rebase, heh, I almost never agree with John Goerzen. What nobody seems to recognize is that the problems with rebase are simply a matter of namespace control. (That's something that Tom Lord really got right with Arch, although he took it too far.) It's simple to demonstrate this: if you don't use git-gc, *git never loses any history, ever*. It's just inconvenient to get at. So there's no conflict in the DAGs. So what's the problem? Well, at the concrete level, it's analogous to the problem that using global variables to hold local data isn't thread-safe. At the meta level, it's a confusion between branch *names* and branches as *chains of commits*. I'd be willing to place a bet that the reflog mechanism will eventually make git-rebase thread-safe, because it records discontinuities as a rebase. A thread-safe git would either error, or possibly do something smart, when trying to pull from a branch that has been rebased. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta