2009/9/14 Ted Gould <ted@...11...>:
Regarding an easy "uncommit" command: One of the main reasons I love git is that you have incredible power with undoing commits, reordering commits, combining multiple commits in a single one, etc. I'd be interested which of this is possible with bzr.
You can do most of that with the bzr-rebase plugin, but I'd recommend against it. Honestly, the only reason I've seen to reorder commits is to lie and say you never make mistakes, or to clean up a visualization to make it look better. I don't think either of those are good reasons to "change history." I'm kinda a historian on that point, it seems like history is history -- leave it alone :)
I agree as far as the "official" history is concerned (i.e., the history of the central repository). But for things like finding (and especially understanding!) the commit where a bug was introduced, I find it immensely helpful if commits come in chunks of reasonable size, are relatively self-contained and do sensible things. For this reason I am *very* grateful that git allows me to rewrite my (local!) history before pushing my changes. It's not so much about not admitting mistakes but rather about helping others not to have to go through these same mistakes again when investigating your development later on. I guess it depends on your workflow as a programmer, but in my work I often find that I have to take a slightly different approach than originally intended, and if rearranging commits helps me to present a cleaned up version of my work to others then I'm all for it.
And, while git can do it, it's not nearly as simple as "uncommit". You have to use some commands with really scary sounding arguments to pull that off.
You mean scary commands like
git reset HEAD~n
in order to undo the last n commits? :-P
Max