Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: > >> ... In this command, I obviously don't want to move the HEAD, >> so why the hell should git refuse "git reset --hard -- file1 >> file2"? > > (1) because allowing it begs the question "what would happen if > I replace that --hard with --soft", the answer to which has > to be "nothing happens". That answer is logically correct > but not useful from the end user's point of view; True, but that's already true of "git reset --hard", alone, isn't it? Unless I missed something, "git reset --soft" is a no-op if you don't provide arguments. > (2) because it is a good idea to remove "git reset --mixed -- > file1 file2" and spell it without --mixed in order to reduce > confusion, after which happens the "--hard" variant would > become even more special case; Valid point. If you deprecate "git reset --whatever" with path names, adding it to "git reset --hard" now would be a mistake. > (3) because there already is "git checkout HEAD -- file1 file2". That means the commands overlap. To me, that's not a real issue. If someone types "git reset --hard -- file1 file2", since the expected behavior is obvious, it's better to have git do the obvious than die IMHO. > Having said that, if more synonyms make users less confused, > then I think the following is possible: > > (1) grabbing paths out of an existing commit and updating both > index and work tree has two synonyms: > > $ git reset --hard <commit> -- paths... <*> > $ git checkout <commit> -- paths... > > (2) grabbing paths out of an existing commit and updating only > the index has three synonyms: > > $ git reset --mixed <commit> -- paths... > $ git reset <commit> -- paths... > $ git checkout --cached <commit> -- paths... <*> I don't like "git checkout --cached" for the reason you mention later. > (the word "checkout" has stronger association with work tree than > the index). And your (2) doesn't sound like a natural extension. It's actually one more option to checkout. My point about "git reset --hard" is that you're told here and there to use "git reset --hard" to revert uncommited changes, "git reset" already accepts path arguments, so it seems strange to forbid them in this case. I'm not talking about adding aliases for the pleasure of adding aliases. But as told above, that argument doesn't hold if you deprecate path arguments also for --mixed. -- Matthieu - 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
