Junio C Hamano <gitster@xxxxxxxxx> writes:
> Matthieu Moy <Matthieu.Moy@xxxxxxx> writes:
>
>> Junio C Hamano <gitster@xxxxxxxxx> writes:
>> ...
>>> And why not "git checkout HEAD file" as the user manual teaches
>>> you to?
>>
>> I don't see any mention of "git checkout HEAD" in the user manual.
>
> "git checkout <arbitrary-commit> paths" would universally cover
> that. Do you really want to see the documentation to spoon feed
> any and all possible <arbitrary-commit> as example there?
You adress my second point, but not the other one, that you didn't
quote:
>> But "Checking out an old version of a file" is not the place one
>> should search for this,
Really, someone searching the user manual for "how to cancel the work
I did in a single file", finding a section "Fixing mistakes" with the
way to do this for all files would have expected to find the way to do
it for individual files just next.
> Give us a break.
You are a core developer of git, and therefore, you probably never
actually _had_ to search the user manual for something. I was
therefore assuming that you were interested in the opinion of someone
who actually had to, and who didn't find the answer in the expected
place.
I know that many people on this list are happy with git and it's
documentation, but any time I try to talk about git to someone else,
the answer is close to "Ah, you're talking about this thing written by
kernel developpers for kernel developpers, and unusable by anyone
else?". I'm just trying to change that (yes, I acknowledge that a lot
of work has already been done in that direction, and that my
contribution is small).
>> There's this:
>>
>> Checking out an old version of a file
>> [...]
>> $ git checkout HEAD^ path/to/file
>>
>> But "Checking out an old version of a file" is not the place one
>> should search for this,
>
> Why not? If HEAD^ works, then HEAD would work and "next" or
> "v23" by natural extension, wouldn't it?
Technically, "Checking out an old version of a file" and "reverting a
file to HEAD" are the same, but they're totally different in the flow,
from the user point of view.
You really don't write
$ git checkout HEAD^ ...
for the same reason you'd write
$ git checkout HEAD ...
> I am really reluctant to add arbitrary synonyms to mollify users
> who refuse to learn the lingo of the land. Next person would
> demand "Hey that is about recovering my file from the head, so
> you should call that 'git recover'", and as we continue to add
> "git resurrect", "git bringback", "git restore", the resulting
> mess would confuse everybody.
I'm also opposed to introducing a new command.
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".
At least, the error message should point to git-checkout. Something
like this perhaps:
diff --git a/git-reset.sh b/git-reset.sh
index 1dc606f..589fdb1 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -44,7 +44,7 @@ case "$1" in --) shift ;; esac
if test $# != 0
then
test "$reset_type" = "--mixed" ||
- die "Cannot do partial $reset_type reset."
+ die "Cannot do partial $reset_type reset. Use \"git checkout HEAD $@\" instead."
git diff-index --cached $rev -- "$@" |
sed -e 's/^:\([0-7][0-7]*\) [0-7][0-7]* \([0-9a-f][0-9a-f]*\) [0-9a-f][0-9a-f]* [A-Z] \(.*\)$/\1 \2 \3/' |
--
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
