On Sun, Mar 23, 2008 at 08:14:47PM +0100, Florian Weimer wrote:
quoted text
> 
> 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


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html