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

Michael Sperber writes: Indeed. git's failure to track patch identity is a defect. I'm not yet convinced it's a design defect (nor do I claim to be sure it's not). I believe git can be extended to track patches without changing repo format, or at worst with the addition of a new object type. I haven't actually tried to do it yet, though. (To be honest, I have so little use for patch identity, vs. revision identity, that I haven't even checked if Stacked Git does what I think is DaRightThang.) 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". Things are a little less clear when "F" is a sequence of patches branching at "D", but rebase does basically the same thing in that case as merge does in the one patch case. In both cases I could do the work at "C" even if there were no conflicts, but I probably wouldn't bother. 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". If I'm careful about all the above, I can then push "I", and naive use of the "~N" operators by third parties to get mainline parents will DTRT, while the full history is available to anyone who wants to try to figure out "WTF Steve was thinking?!?" 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. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta