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

Now, why doesn't that bother me? In my usage, for that reason I don't use rebase except when I find an irreversible change necessary. While I'm working, I have something like this: current tip | | V V A --- B --- C --- D --- E So the "current" branch is there, but I know I can always revert to "tip". I manipulate "current" with "git reset". If I need to commit to "current" because "C" is unsatisfactory and the needed change "F" conflicts with "D", a merge of "current" into "tip" does the right thing: it leaves "C" and "D" alone, with the mainline history indicating that "G" (the merge commit) follows "E", and the branch history showing that "G" is conceptually based in "F" but required alteration to work with "D" and "E".

Finally, at the time of submitting, I might change my mind, and rebase "D---E" on "F", getting "H" which will have the same tree as "G".

(This can be efficiently checked by extracting the tree SHA1s and comparing.)

Or I might use cherry-pick to extract and coalesce "A---B", "C---F", and "D---E" into three "coherent" patches, and arrange them as AB --- CF --- I where "I" is a new commit (since "CF" is a new parent), and has the same tree as "H" and "G".

I find this all totally intuitive, YMMV.

I find this all totally intuitive, YMMV. Certainly the git UI leaves a lot to be desired (but it's improving rapidly). It took me a long time to figure *how* to do all that and that it would do the right thing.