Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: > 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. I think I see where you are coming from. To you "git reset" (any of three reset_type) is something special and different from "git reset <any-commit>". If we take that approach, "git reset" and "git reset HEAD" can behave differently and you can certainly argue "git reset --soft" is a no-op. To me, it is just a shorthand of not giving an explicit commit (and defaults to HEAD), and it is not particularly special. Neither "git reset --hard not-HEAD" nor "git reset --soft not-HEAD" is a no-op. That makes "git reset --soft not-HEAD -- paths" being a no-op doubly confusing while "git reset --hard not-HEAD -- paths" does what exactly "git checkout not-HEAD -- paths" does. - 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
