All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Kevin Daudt <me@ikke.info>, Git Mailing list <git@vger.kernel.org>
Subject: Re: "man git-checkout", man page is inconsistent between SYNOPSIS and details
Date: Sun, 01 Oct 2017 12:49:38 +0900	[thread overview]
Message-ID: <xmqqo9prv86l.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.LFD.2.21.1709301800060.7869@localhost.localdomain> (Robert P. J. Day's message of "Sat, 30 Sep 2017 18:04:05 -0400 (EDT)")

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:

>   it's simply a matter of the forms not matching between the SYNOPSIS
> and the DESCRIPTION sections. am i making sense?

I think the whole thing is wrong and the root cause is because the
(relatively newer) description of the "--patch" mode lazily tried to
piggy-back the description of existing "check out from the index or
tree-ish" mode, ending up in a confusing description.

"git checkout [<tree-ish>] -- <pathspec>..." is a way to overwrite
the working tree files with what is in the object store.  When you
give <tree-ish>, the paths that match the <pathspec> are grabbed
from the tree-ish, added to the index, and overwrites the working
tree files.  In this mode, you need to have at least one pathspec
element on the command line, so <pathspec> is mandatory.  With no
pathspec, if <tree-ish> happens to be a commit-ish, then the
operation is "check out the commit, so that we can prepare to make
a new commit as its child".

"git checkout -p/--patch [<tree-ish>]" is quite different.  It can
be used without any <pathspec> to pick and choose from all changes
treewide, but you can use <pathspec> to limit the changes you need
to choose from.

Something like the following may be a good starting point.  As I
didn't spend many brain-cycles to come up with a description for the
"--patch" mode, that paragraph needs a total rewrite on top, but I
think the structure to separate the normal "per-path" checkout mode
and "patch" mode and describe it separately should make it a lot
clearer to see what is being described.

Short of such a fundamental correction,

	git checkout [-p|--patch] [<tree-ish>] -- [<pathspec>...]

would allow you to give none of -p/--patch/<pathspec>, which is
totally a different operation from what is being described in the
text.

 Documentation/git-checkout.txt | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index d6399c0af8..3d88f703e9 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -13,7 +13,8 @@ SYNOPSIS
 'git checkout' [-q] [-f] [-m] [--detach] <commit>
 'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
-'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]
+'git checkout' [<tree-ish>] [--] <pathspec>...
+'git checkout' (-p|--patch) [<tree-ish>] [--] [<paths>...]
 
 DESCRIPTION
 -----------
@@ -78,10 +79,9 @@ be used to detach HEAD at the tip of the branch (`git checkout
 +
 Omitting <branch> detaches HEAD at the tip of the current branch.
 
-'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
+'git checkout' [<tree-ish>] [--] <pathspec>...::
 
-	When <paths> or `--patch` are given, 'git checkout' does *not*
-	switch branches.  It updates the named paths in the working tree
+	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
 	meaningless and giving either of them results in an error.  The
@@ -89,7 +89,7 @@ Omitting <branch> detaches HEAD at the tip of the current branch.
 	(i.e.  commit, tag or tree) to update the index for the given
 	paths before updating the working tree.
 +
-'git checkout' with <paths> or `--patch` is used to restore modified or
+'git checkout' with <paths> is used to restore modified or
 deleted paths to their original contents from the index or replace paths
 with the contents from a named <tree-ish> (most often a commit-ish).
 +
@@ -101,6 +101,13 @@ specific side of the merge can be checked out of the index by
 using `--ours` or `--theirs`.  With `-m`, changes made to the working tree
 file can be discarded to re-create the original conflicted merge result.
 
+'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
+	This is similar to the "check out paths to the working tree"
+	mode described above, but lets you use the interactive
+	interface show the "diff" output and choose which hunks to
+	use in the result.
+
+
 OPTIONS
 -------
 -q::

  reply	other threads:[~2017-10-01  3:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-30  9:27 "man git-checkout", man page is inconsistent between SYNOPSIS and details Robert P. J. Day
2017-09-30 14:32 ` Kevin Daudt
2017-09-30 15:01   ` Robert P. J. Day
2017-09-30 22:04   ` Robert P. J. Day
2017-10-01  3:49     ` Junio C Hamano [this message]
2017-10-01 10:05       ` Robert P. J. Day
2017-10-02  0:29         ` Junio C Hamano
2017-10-11  2:39           ` [PATCH] checkout doc: clarify command line args for "checkout paths" mode Junio C Hamano
2017-10-11  3:22             ` Jonathan Nieder
2017-10-11  5:02               ` Junio C Hamano
2017-10-11  5:16                 ` Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqo9prv86l.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ikke.info \
    --cc=rpjday@crashcourse.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.