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?
Give us a break.
> 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?
> Still, I think "git reset --hard HEAD file1 file2" should be made
> equivalent...
I do not oppose to use a different word to denote an operation
that we do not have yet. For example, we do not have an
operation that grabs a blob given an existing commit and a path
in it, and update the corresponding work tree file without
affecting the index. You have to do "git show commit:path >path"
but you cannot do this for more than one paths.
But both "update only the index entries for given paths from a
given commit" and "update both the index entries and work tree
files for given paths from a given commit" have established
terminology.
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.
You use the word "checkout" in two ways, distinction between
which is clear from the context:
- You checkout a particular version or specific branch. This
operation moves where HEAD pointer points at (i.e. branch
switching).
- You checkout specific paths outpuf a named version. This is
the operation we are discussing.
You also use the word reset in two ways, again distinction
between which is clear from the context:
- You reset where the HEAD points at to a particular commit.
There are three variants (default, --hard and --soft)
depending on what happens to the index and the work tree.
- You reset specific paths in the index without touching work
tree nor HEAD. That is "git reset <commit> paths...".
git reset COMMIT path
COMMIT -------------------> INDEX
\ /
\ /
git show COMMIT:path >path \ /
(bypassing INDEX) \ /
\ / git checkout -- path
git checkout COMMIT -- path \ /
(with INDEX) \ /
\ /
V V
WORK TREE
-
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
