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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
