On Mon, 2009-09-14 at 20:26 +0200, Maximilian Albert wrote:
2009/9/14 Ted Gould <ted@...11...>:
On Mon, 2009-09-14 at 11:14 -0600, Joshua L. Blocher wrote:
Here is my logic. Lets start here http://whygitisbetterthanx.com/
From the website, there are many things that are off, but the one that bothers me is that they list the feature of "staging area", which is a total misfeature. It basically means you need to commit twice, instead of supporting an easy "uncommit" command.
Personally, I find the staging area quite useful and use it on a regular basis. The reason for this is that it allows me more fine-grained committing during my development work (normally, I realize that it would be sensible to store my changes in a commit when other files are already changed; using the staging area I don't have to undo these newer changes before committing). But maybe that's a personal thing, and if you don't like it you can simply ignore it and commit as you used to with other version control systems (using the -a switch).
Sure, fine-grained is fine. But I don't understand why you need a two phased commit process to do that. And making what most users expect (-a) to be a command line option is more than a little silly.
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 :)
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.
--Ted