Re: What I miss from Cogito...

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Mar 24, 2008, 01:40 UTC
Message-ID: <20080324014030.GA24695@atjola.homenet>
In-Reply-To: <20080324001617.GB24943@mit.edu>

On 2008.03.23 20:16:17 -0400, Theodore Tso wrote:

Show 17 quoted lines

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

There is a difference between "checkout HEAD -- $file" and "show HEAD:$file > $file". The former will also update the index, while the latter does not. Maybe you asked for not updating the index back then? Just guessing...

Show 6 quoted lines

> 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").

Maybe it's just a misunderstanding on my side, but to me "checkout" means as much as "get me something out of the repo". And git checkout does exactly that. It can get you a branch (naturally switching your HEAD to it), or it can get you trees or blobs. The latter can come from either the index (default) or from a specific treeish. To say that you want to revert your local changes is just the same as saying that you want the file as it is in HEAD. And that's what git checkout gives you, without introducing an extra command for that one special case.

Show 5 quoted lines

> 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).

Nah, that would create confusion within git, because it does something totally different from git revert. And checkout can also checkout a whole tree, not just a file. So you would either need revert-tree as well... Or add more confusion, because revert-file "reverting" a tree is not quite intuitive.

Björn