Michael Sperber writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Aidan's last push corrupted the DAG, creating a new head, and
> effectively overwrote .hgtags without the release tag.
I don't think so. In particular, I don't see any of Aidan's commits
making a change to .hgtags,
You wouldn't. When you're on that branch, the version of .hgtags is
unchanged from the node between my release branch and Aidan's through
Aidan's commits. In particular, it doesn't contain the release tags.
But now I can't make the tags disappear in hgk the way they did the
other day. I'm guessing this was some kind of side effect of
resolving conflicts in .hgtags. How I got conflicts in .hgtags, I
> For now, you can get the release with "hg checkout -r
That does not appear to have been pushed.
*sigh* No, it wasn't. The relevant stuff has been pushed now, and a
fresh checkout shows the tags where they should be. (By the way, that
revid is now irrelevant: the public DAG is different from the one I
was looking at when I posted that.)
I'm not sure why I thought anything was pushed to bitbucket; maybe the
"pushing to ..." line scrolled out of sight. But after many years
always checking out from the public repo for release work, I changed
my production configuration to use a local repo as source (for
checkouts for adding release heralds to the ChangeLogs and
makepatch'ing) when we switched to Mercurial. So evidently the push
You mean git doesn't let you make pilot errors?
Sure it does. It's just that they've always been easy to fix (YMMV
;-), and using everyday git operations to play with the DAG is
nondestructive, so experimenting is risk-free. And I never get
confused about where I'm pushing to. Even when I have multiple
workspaces, I do everything out of one GITDIR. So the remote relative
to git's configuration is always the public repo, never something
XEmacs-Beta mailing list