Re: What I miss from Cogito...

From: Theodore Tso <tytso@mit.edu>
Date: Mar 24, 2008, 00:16 UTC
Message-ID: <20080324001617.GB24943@mit.edu>
In-Reply-To: <87r6e1b6c8.fsf@mid.deneb.enyo.de>

On Sun, Mar 23, 2008 at 08:14:47PM +0100, Florian Weimer wrote:

Show 8 quoted lines

> 
> Personally, I'm not all that happy with the multiple different meanings
> of "git reset" and "git checkout", either.  Depending on the parameters,
> the two comments manipulate both the contents of the working copy, or
> the location at which the working copy is hooked in the history.  If we
> need to have two separate commands for this, it would make more sense to
> draw distinction between the two aspects, and not the mess we have now.
> OTOH, it's probably too late for that.

Yeah, it's not at all intuitive. I've been using git for quite some time and had *absolutely* *no* *idea* that "git checkout <treeish> -- path" did what "bk revert" and "hg revert" does. In fact, I'm pretty sure I remember asking for this functionality a while back, and being told the right answer was "git show HEAD:pathname > pathname", and I kept on typing it until I got sick and tired of it, and so I created my short-hand shell script.

And the fact that Peter was using "git reset --hard -- pathname" is another hint that it isn't at *all* obvious that "git checkout" does two completely different things, and it's not something that you're likely to intuit from the name or looking at the top-level git man page (where the summary in the top-level git manpage is, "checkout and switch to a branch").

If we were going to separate the two commands out, I'd use the name "git revert-file", because that's what people who are coming from bk or hg are used to (where "revert" means to undo the local edits done to a particular file, as opposed to the git meaning of undoing a particular commit).

						- Ted