Re: Mercurial "r####" numbers are not stable, use commit ids
Michael Sperber writes:
I still don't understand what your problem is.
Mercurial makes it somewhat hard to do what I want to do (work in
branches), makes it easy to make mistakes in that mode, and makes it
hard to produce high S/N log listings and diffs.
(You seem to prefer git, but it has essentially the same underlying
model as Mercurial, AFAICS.)
Sure, and Scheme and Emacs Lisp share an underlying model, too. As
usual the devil's in the details. For example, I think that exposing
unstable revnos to the world is bad UI. The no-argument merge command
is bad UI (at least if both heads are on named branches). The fact
that a branch is not treated as a head if it's a proper ancestor of a
head is unintuitive to me, although I'm not prepared to categorize it
as "bad" yet. The fact that tags are commits is ugly. The fact that
a branch has no existence until you commit to it worries me. I can't
think of a "real" use for it, but when writing the script that I
posted for Mats I realized that an empty branch is useful for
simulating concurrency in a single-user context. So there might be
some odd case where it would be really nice to have such a thing.
> I did merge locally (if you thought about it, you'd realize
that,
> because Mercurial won't push if it creates a head), but unfortunately
> there were only two heads so "hg merge" just worked and then push did
> the wrong thing by creating a branch (in almost five years of working
> with distributed VCSes I've only *wanted* push to create a new remote
> branch once). Worse yet, it was totally silent about it.
Normally Mercurial refuses to create remote branches unless the -f
option is specified. Could you be more specific about what you did?
What is written above is what I can remember or deduce about what I
did. All I can add is that the "bytecomp" branch was transplanted to
the end of the "g++-warnings" branch, that in my repo the most recent
commit to "default" was a proper ancestor (merge parent) of the
"bytecomp" head at the time of the push, and that I would NEVER EVER
specify -f to a push to the "xemacs" repository.
Are you sure that "hg push" knows anything about branches? AIUI in
Mercurial "branch" is an attribute of a commit, and single-valued, it
seems (unlike git, where a branch is implemented as an automatically
updated ref, all branches implicitly go back to a root, and a commit
can be on several branches simultaneously). ISTM that hg push has no
need-to-know about "branch", and that the restriction is against
creating new heads. A branch just goes along for the ride, because a
non-trivial branch will have a head.
So my guess is that because tip happened to be on bytecomp when I
pushed, and it was the only head (default didn't have one), hg push
happily pushed it to the xemacs repo, and reset tip of that repo to be
on my branch (possibly because default was inactive).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta