git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Thomas Weißschuh" <thomas@t-8ch.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Documentation: mention the magic pathspec ":/"
Date: Sun, 14 Aug 2022 22:12:12 -0700	[thread overview]
Message-ID: <xmqqsfly3xar.fsf@gitster.g> (raw)
In-Reply-To: 20220814095253.3422612-1-thomas@t-8ch.de

Thomas Weißschuh <thomas@t-8ch.de> writes:

Here before your sign-off is the place for you to justify why this
patch is a good idea.

> Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
> ---
>  Documentation/gitcli.txt | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
> index 1819a5a185..a421855bdb 100644
> --- a/Documentation/gitcli.txt
> +++ b/Documentation/gitcli.txt
> @@ -78,6 +78,8 @@ you will.
>     using a '.' as a repository name in Git (a dot-repository) is a relative
>     path and means your current repository.
>  
> + * The magic pathspec `:/` refers to the root of the working tree.
> +

This looks somewhat out of place.  Reading the previous entry, I
notice it is about the path to a repository, not about path in your
working tree.  The entry before it is about pathspec, so in a sense,
what is truly out of place is the "dot is how you refer to the
current repository".

I do not quite see why we want to single out ":/", i.e.  the "top"
pathspec magic applied to an empty string, and not talk about the
case when it was applied to non-empty string, e.g.  ":/*.c".  If we
talk about pathspec magic, shouldn't we also talk about "exclude"
magic, e.g. ":!\*.o", here?

Besides, the new description is not exactly correct. The "top"
pathspec magic does not inherently refers to the root.  In

    $ cd sub/dire/ctory && git grep -e pattern

we tell "git grep" to look for patterns in the current directory
and in its subdirectories, and with

    $ cd sub/dire/ctory && git grep -e pattern :/

we lift the "current directory and below" limitation and instead
look for matches everywhere, not limited to the root-level directory.
We can find a patch from sub/foo.txt that is neither in our current
directory or at the root-level directory.

So, I do agree that the users must know more than "Many commands
allow wildcards in paths" (the entry before the "dot is how you can
refer to the current repository"), I do not think singling out ":/"
and refer only to that is a wrong way to go about it for this
document.  The gitcli manual does not even mention 'pathspec', which
is the keyword to effectively find many things to learn in the
glossary ("git help glossary"), and it would be the first thing to
fix here, I would think.

So after reading your patch and thinking about it for a few days,
here is what I think is wrong in the current description, plus its
fix.

Thoughts?

 Documentation/gitcli.txt | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git c/Documentation/gitcli.txt w/Documentation/gitcli.txt
index 1819a5a185..40553fc578 100644
--- c/Documentation/gitcli.txt
+++ w/Documentation/gitcli.txt
@@ -57,9 +57,11 @@ When writing a script that is expected to handle random user-input, it is
 a good practice to make it explicit which arguments are which by placing
 disambiguating `--` at appropriate places.
 
- * Many commands allow wildcards in paths, but you need to protect
-   them from getting globbed by the shell.  These two mean different
-   things:
+ * Many commands take paths to work on as "pathspec".  A pathspec element
+   can be a literal string, which specifies the named path itself, or it
+   can be a wildcard pattern, which specifies all paths that match the
+   pattern.  Wildcards may need to be protected from getting globbed by
+   the shell.  These two mean different things:
 +
 --------------------------------
 $ git restore *.c
@@ -73,6 +75,8 @@ the paths in the index that match the pattern to be checked out to your
 working tree.  After running `git add hello.c; rm hello.c`, you will _not_
 see `hello.c` in your working tree with the former, but with the latter
 you will.
++
+To learn more about pathspec, see linkgit:gitglossary[7].
 
  * Just as the filesystem '.' (period) refers to the current directory,
    using a '.' as a repository name in Git (a dot-repository) is a relative

  reply	other threads:[~2022-08-15  5:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-14  9:52 [PATCH] Documentation: mention the magic pathspec ":/" Thomas Weißschuh
2022-08-15  5:12 ` Junio C Hamano [this message]
2022-08-16 14:08   ` Thomas Weißschuh

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqsfly3xar.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=thomas@t-8ch.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).