git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Junio C Hamano'" <gitster@pobox.com>
Cc: <git@vger.kernel.org>
Subject: RE: [Patch 2/3] Documentation/config.txt: add worktree includeIf conditionals.
Date: Wed, 14 Jul 2021 09:46:52 -0400	[thread overview]
Message-ID: <006b01d778b6$b74b8600$25e29200$@nexbridge.com> (raw)
In-Reply-To: <xmqqr1g1zow4.fsf@gitster.g>

On July 13, 2021 9:05 PM. Junio C Hamano wrote:
>randall.becker@nexbridge.ca writes:
>
>> From: "Randall S. Becker" <rsbecker@nexbridge.com>
>>
>> Documentation of the worktree and worktree/i conditionals is add based
>> on gitdir rules except that the trailing / form of the path is not supported.
>>
>> Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
>> ---
>>  Documentation/config.txt | 11 ++++++++++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt index
>> bf82766a6a..7e951937ae 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -143,7 +143,16 @@ refer to linkgit:gitignore[5] for details. For convenience:
>>
>>  `gitdir/i`::
>>  	This is the same as `gitdir` except that matching is done
>> -	case-insensitively (e.g. on case-insensitive file systems)
>> +	case-insensitively (e.g. on case-insensitive file systems).
>> +
>> +`worktree`::
>> +	This is similar to `gitdir` except that matching is done with
>> +	the path of a worktree instead of the main repository. Unlike
>> +	`gitdir`, the trailing / form of the worktree path is not supported.
>
>It is not immediately obvious what "the trailing / form" means.
>
>Does it refer to the 4th item in the 4-bullet list in the description just above the patch context (I am trying to make a guess
here)?
>
>The problem I perceive in this description is that there is no phrase "trailing" in the vicinity of what readers have read so far;
readers who
>are not exactly familiar with the system may need a bit more assurance that they guessed correctly.
>
>    Unlike `gitdir`, `**` will not be automatically added to a
>    pattern that ends with `/`
>
>would be easier to give that assurance, albeit more verbosely.
>
>Assuming that I guessed correctly, is this a deliberate design decision not to "automatically add ** after a pattern that ends with
a slash",
>and if so why?  I would have thought that "in the worktrees that I create inside /var/tmp/, please enable these configuration
variables"
>would be a fairly natural thing to ask, and I do not immediately see a reason why we want to apply different syntax rules between
"gitdir"
>and "worktree".

The reason for this comes down to what is in *the_repository. Essentially, the_repository->gitdir always has a /path/to/.git
directory with full qualification. the_repository->worktree does not have /.git added for obvious reasons, so the /path/to is bare
of the trailing /. This causes a trailing pattern /to/path/** match to fail. I could copy the value into a working buffer but that
seemed a bit clunky. So using the available information, the syntax rules need to be different between the two, unless the value of
worktree is augmented. I was unsure which way the team wanted to go on this.


  reply	other threads:[~2021-07-14 13:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-12 22:31 [Patch 0/3] includeIf series for worktrees randall.becker
2021-07-12 22:31 ` [Patch 1/3] config.c: add conditional include based on worktree randall.becker
2021-07-13 13:03   ` Johannes Schindelin
2021-07-12 22:31 ` [Patch 2/3] Documentation/config.txt: add worktree includeIf conditionals randall.becker
2021-07-14  1:04   ` Junio C Hamano
2021-07-14 13:46     ` Randall S. Becker [this message]
2021-07-14 17:10       ` Junio C Hamano
2021-07-14 17:30         ` Randall S. Becker
2021-07-12 22:31 ` [Patch 3/3] t1305: add tests for includeIf:worktree randall.becker

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='006b01d778b6$b74b8600$25e29200$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --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.
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).