Hi, I'm one of those wannabe experts who thinks he knows enough about git to teach people in his workplace but obviously pales in this group, but with that caveat, let me say: 2009/8/14 Michael Haggerty <mhagger@xxxxxxxxxxxx>: > Now that you mention it, there are some other uses of rebase whose > history could be recorded correctly, or at least better, in the DAG. I > am not ready to advocate any of these changes, but I think they are I see you've made your own caveat :-) > worth discussing. [snip] > A---B1---B2----C > \ \ \ > ---------B12---C' > A---B12---C > \ \ \ > B1---B2---C' [snip] > A---C > \ \ > B---C' [etc etc... many such snipped] To me, the ability to *forget* the mistakes I made (for whatever definition of "mistake" you wish) as long as it's private to my repo, is one of the main attractions of git. I'm one of those guys who saves early, and saves often, when editing files. This translates to commit early, commit often, in the git world. I see no earthly reason why I would ever *want* those commits preserved, so I hope that, if this sort of thing ever gets into the code, it is definitely *not* the default :-) It is not sufficient for me that the GUI knows how to suppress their display, it is necessary that they *disappear completely*. And that reminds me. You often hear people on #git ask how to get rid of some files (maybe containing passwords etc) that inadvertently got into the repo, and the answer, a lot of the time, is filter-branch, because the "bad" commit is pretty old. I suspect that for every person who asks that question on the list because he already pushed, there are 4 who discovered such an error much earlier, (when the file went into only a couple of commits at the top maybe), did a rebase -i with "edit" or whatever, and got rid of the evidence, err I mean password :-) If this sort of thing were to be the default, they'd have to use a filter-branch even for such simple cases. Finally, speaking as someone who teaches git, this adds enormous complexity to the basic concepts. Complexity is good when the benefits are obvious, but to me they are not obvious [see *my* caveat at the top before you react to this statement] -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html