Re: [PATCH] git-checkout.txt: Document "git checkout <pathspec>" better
On 2015-06-10 17.05, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
(Need to drop Eric from CC-list(
Show 18 quoted lines
>> git checkout <pathspec> can be used to revert changes in the working tree.
>
> I somehow thought that concensus in the recent thread was that
> "restore", not "revert", is the more appropriate wording?
>
> And I think that is indeed sensible because "revert" (or "reset")
> already means something else in Git (and in other systems), while
> "restore" does not have a confusing connotation. It can only mean
> "overwrite with a pristine copy", which is what the command is
> about.
>
>> -git-checkout - Checkout a branch or paths to the working tree
>> +git-checkout - Switch branches or reverts changes in the working tree
>
> Two verbs in different moods; either "switch branches or restore
> changes" or "switches branches or restores changes" would fix that,
> and judging from "git help" output, I think we want to go with the
> former, i.e. "switch branches or restore changes".
Show 12 quoted lines
>
>>
>> SYNOPSIS
>> --------
>> @@ -83,7 +83,8 @@ Omitting <branch> detaches HEAD at the tip of the current branch.
>> When <paths> or `--patch` are given, 'git checkout' does *not*
>> switch branches. It updates the named paths in the working tree
>> from the index file or from a named <tree-ish> (most often a
>> - commit). In this case, the `-b` and `--track` options are
>> + commit). Changes in files are discarded and deleted files are
>> + restored.
>
Show 6 quoted lines
> How about this?
>
> 'git checkout' with <paths> or `--patch` is used to restore
> modified or deleted paths to their original contents from
> the index file or from a named <tree-ish> (most often a
> commit) without switching branches.