Junio C Hamano <gitster@xxxxxxxxx> writes: > Are you saying that [...] "you do write 'checkout HEAD > path' but the reason you would want to do so is totally > different from you would want to write 'checkout HEAD^ path' and > there is no similarity"? This one. > Because checking out from the HEAD can be written "git checkout > HEAD path", it is fairly natural that "get that thing from one > rev back" is "git checkout HEAD^ paths". So the second > interpretation does not hold either. There is a parallel > between the two. I don't see the relationship between the two parts of your sentence. You write $ git checkout HEAD^ file.c when you realize _after_ commiting that you made an error, and only if you want to keep the mistake in the history (i.e. not rewrite history). You'll have to commit afterwards if you're OK with it. The use-case is similar to "git revert". You write $ git checkout HEAD file.c when you realize you went the wrong way starting something, and you did not yet commit it. You don't have to commit afterwards. The use-case is similar to "git reset". Those two use-cases are very well distinguished in the user manual, but there's no mention of git-checkout in the part above "fixing mistakes with a new commit". >> But since "git reset" already accepts partial resets in some >> circumstances, I think it makes sense to slightly extend it to allow >> partial reset in the case of "git reset --hard HEAD". > > But how would you explain "git reset --hard HEAD~24 paths"? > Does it move HEAD or not (rhetorical: it shouldn't)? Read carrefully the very last line of the citation above your questions. -- 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
