Re: Mercurial "r####" numbers are not stable, use commit ids

Michael Sperber writes: No, I *definitely* don't want the -C, and if I do have AFAICT when you do "hg qpop", the changeset disappears irreversibly. When you do "hg qpush", the same patch is reapplied but a new changeset is created. Am I missing something? I don't know what you're talking about "implies a merge" -- so let's not worry about it, just assume I wrote something meaningless and forgot to delete it before sending. No, reset (without a file argument) by default affects the index and HEAD and leaves the working tree alone. (The index is where the "add", "remove", and "to commit" state is stored, among other things.) The revision history itself is immutable except by "git gc --prune". "git reset --hard" is exactly equivalent to "hg update -C", I think. So, for example if I do # make changes git commit -m "first" # make changes git commit -m "second" git tag tip git reset HEAD^ then the index ("git status", more or less) will show that I've got the changes in "second" in the workspace, but HEAD will point to the commit logged as "first", and a new commit will have the commit logged as "first" as its parent. If I use the "--soft" flag, then the index will show that all of those changes are staged for committing. Finally, I can do "git reset tip" and I'll be back where I started. To use the Lisp analogy, HEAD is a (magic) variable containing a commit. A commit is basically a cons. All information except ancestry is encapsulated in the car of a commit, the parent is the cdr. "git commit" is like "(push (make-commit-info) HEAD)". "^" is the cdr operation, and "~" is nthcdr. "git reset" is basically "setq"; without --soft or --hard, it has no implicit side effects, just the explicit one. So "git reset HEAD^" is just "(setq HEAD (cdr HEAD))". "git tag" and "git branch" also are basically "setq". The naive Lisp analogy fails at two points. First, a git commit's "cdr" can be multivalued, ie, if it's a merge commit. Second, HEAD is "(magic)" because its value is normally not a commit, it's a branch. The branch is automatically dereferenced to a commit in all contexts I know of (except if you cheat and look from outside of git at the symlink or file that is the OS-level implementation of HEAD), and the branch doesn't appear in a log listing, etc. So this magic dereference is transparent to the user; HEAD looks like a commit to her. Yeah, well, somebody whose favorite tool is something called "queue" whose primary mode of operation is stack-like can't complain about confusing docs. :-) I have to admit that the git nomenclature seems designed to put off newbies and people who "just want to use the tool dammit!" No, I don't want to undo the commit, at least to the extent I need to replicate git behavior. I want to change hg's idea of what commit is at the head of my current branch, without losing the commits I've made. I'm not really sure what I actually need, just that everything I try to do in hg seems either to be impossible or to pollute the public namespace. :-P Do tags and branch points move too? I suspect not. (In git they don't move when you rebase, but I don't use rebase to emulate patch stacks in git.) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta