All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. Adam Nielsen" <admin@in-ici.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH/docs] make slash-rules more readable
Date: Wed, 17 Apr 2019 17:49:42 +0200	[thread overview]
Message-ID: <CAKrvxcXrnEdVFHxrEhhcFB5knXF1V=Jtf0psVVaK-Q=KVEztTg@mail.gmail.com> (raw)
In-Reply-To: <CAKrvxcX+Fi1U4NcH5Mqf0cR8QQc9FWtVQ-uuj0Dhd3qEu5o6XA@mail.gmail.com>

I think its maybe hard to track all the changes that we have discussed
so far. Should I create a new PATCH request including all the changes
from the recent mails and then we continue the discussion from there?

Best regards,
Adam

Am Mi., 10. Apr. 2019 um 09:39 Uhr schrieb Dr. Adam Nielsen <admin@in-ici.net>:
>
> > the pattern is matched against paths in the directory where the
> > `.gitignore` file that has the pattern in it is in, and any of
> > its subdirectories (recursively).
>
> > the pattern will match in all directories relative to
> > the `.gitignore` file, with infinite depth.
>
> I could not catch the difference between the meaning of both.
> However, I think "paths in the directory" and "directories relative to"
> are maybe both ambiguous.
>
> Since a pattern without a non-trailing slash must always be a file name or a
> folder name, and does not have a leading slash, we could maybe just
> say it like this:
>
>         the pattern is matched against all files and folders (recursively)
>         from the location of the `.gitignore` file.
> ---------
>
>
> > Unlike a pattern without a slash, a pattern with a
> > non-trailing slash is matched against paths immediately in
> > the directory the `.gitignore` file the pattern appears in
> > is stored in, and does not get used in its subdirectories..
>
> I think one can always assume that we talking about the relevant
> `.gitignore` file (where the pattern appears in).
>
> Perhaps this covers it all?
>
>         A pattern with a non-trailing slash is always considered
>         to begin at the `.gitignore` file location.
>
> followed by your example
>
> > For example, the pattern `doc/frotz/` that appears in
> > `.gitignore` at the top-level of the project matches
> > `doc/frotz` directory (again, seen from the top-level), but
> > not `a/doc/frotz`.
>
> and maybe one more example
>
>         Note that the pattern `doc/frotz` and `/doc/frotz` are
>         equivalent.
>         However `/bar` and `bar` are different. They both match the
>         `bar` file or folder at the top level, but only the latter
> will also match `foo/bar`
>         (when `foo` is at the top level).
>
> This avoids the hustle with the ambiguous path, where it starts, and
> trailing or leading slashes. Together with the
> two examples it seems to be a good compromise between accuracy and
> understandable.
>
> The alternative would be to say
>
>         A pattern with a non-trailing slash is only matched against any
>         path that begins in the directory of the `.gitignore` file.
>
> While this is maybe clearer then saying "pattern [...] always
> considered to begin at` it is ambiguous about the slashes.
> So a very accuracy but maybe less understandable version would be
> something like this:
>
>         A pattern with a non-trailing slash is only matched against any
>         path that begins in the directory of the `.gitignore` file.
>         For example, if the `.gitignore` file is in folder `doc`
>         the path to file  `bar/doc/a/foo` that begins in `doc` is `a/foo`.
>         A pattern that matches a path except for a leading slash or
> trailing slash
>         is still considered a match. It is still valid however,
>         that when a pattern ends with a slash, it would only find a
> match with a directory.
>
> ---------
>
> > Also, a pattern "/doc" matches doc at the current level (i.e. the
> > directory in which .gitignore file that the pattern was taken from
> > is found) and not in any subdirectories.  Is that clear in the
> > proposed update?
>
> Yes.
>
> However, in the docs is already one paragraph solely dedicated for this case:
>
> > A leading slash matches the beginning of the pathname. For example, "/*.c" matches
> > "cat-file.c" but not "mozilla-sha1/sha1.c".
>
> However, we have already a better and more in detail explained example
> in the new
> proposal `*` paragraph and and the case with the leading slash is
> now a sub-case of `A pattern with a non-trailing slash`
> so we might just get rid of the above paragraph?
> ----------
>
>
> Thank you for explaining me how the algorithm works procedurally.
> It gave some inside of the origin of "If the pattern ends with a slash, it is
> removed for the purpose of the following description.."
> ---------
>
> All the best,
> Adam

      reply	other threads:[~2019-04-17 15:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-05 20:00 [PATCH/docs] make slash-rules more readable Dr. Adam Nielsen
2019-04-08  7:51 ` Junio C Hamano
2019-04-08 10:27   ` Dr. Adam Nielsen
2019-04-09  7:01     ` Junio C Hamano
2019-04-09 12:19       ` Dr. Adam Nielsen
2019-04-09 16:21         ` Junio C Hamano
2019-04-10  7:39           ` Dr. Adam Nielsen
2019-04-17 15:49             ` Dr. Adam Nielsen [this message]

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='CAKrvxcXrnEdVFHxrEhhcFB5knXF1V=Jtf0psVVaK-Q=KVEztTg@mail.gmail.com' \
    --to=admin@in-ici.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.