mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Emily Shaffer <>
Cc: Derrick Stolee <>,
Subject: Re: ds/maintenance-part-3 (was Re: What's cooking in git.git (Nov 2020, #02; Mon, 9))
Date: Mon, 16 Nov 2020 16:40:35 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Emily Shaffer's message of "Mon, 16 Nov 2020 15:56:42 -0800")

Emily Shaffer <> writes:

> Because 'git maintenance unregister' spins a child process to call 'git
> config --unset maintenance.repo <cwd>', it actually fails if "cwd"
> contains a POSIX regular expression special character:
>   git config [<file-option>] --unset name [value_regex]

Good find.  And it is even worse that value_regex uses ERE, not BRE,
which means even an otherwise innocuous letter like '+' cannot be
used without quoting.

> You can demo it for yourself like so:
>   git init repro+for+maintenance
>   git maintenance register
>   git maintenance unregister
>   echo $?	# returns '5'
>   git config --list --global
> I see two paths forward:

0. Quote the value_regex properly, instead of blindly using a value
   that comes from the environment.

> 1. Teach 'git config' to learn either which regex parser to use
> (including fixed), or at least to learn "value isn't a regex", or
> 2. Don't spin a child process in 'git maintenance [un]register' and
> instead just call the config API.

> I'd suggest #2. The config API is very nice, and seems to have a simple
> way to add or remove configs to your global file in just a couple of
> lines. If there's a reason why it's not simpler to do it that way, it's
> my fault for missing the review :)

My short-to-mid-term preference is to do #1 to allow a value to be
spelled literally (i.e. remove entry with _this_ value, and add this
one instead), and optionally do #2 as an optimization that is not
essential.  I do not offhand know how you can make #2 alone fly
without doing some form of #1, as I think the same value_regex that
ought to be ERE to specify entries to be replaced needs to be used
under the cover even if you use "config API" anyway.


  reply	other threads:[~2020-11-17  0:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 23:42 What's cooking in git.git (Nov 2020, #02; Mon, 9) Junio C Hamano
2020-11-10  0:44 ` Elijah Newren
2020-11-10  1:03   ` Jeff King
2020-11-10 13:31 ` ds/maintenance-part-3 (was Re: What's cooking in git.git (Nov 2020, #02; Mon, 9)) Derrick Stolee
2020-11-16 23:56   ` Emily Shaffer
2020-11-17  0:40     ` Junio C Hamano [this message]
2020-11-17  1:07       ` Emily Shaffer
2020-11-17 13:56         ` Derrick Stolee
2020-11-17 19:18           ` Emily Shaffer
2020-11-17 19:34           ` Junio C Hamano
2020-11-17 21:12             ` Derrick Stolee
2020-11-19  2:16               ` Junio C Hamano
2020-11-19 13:25                 ` Derrick Stolee
2020-11-19 15:53                   ` Derrick Stolee
2020-11-19 18:06                   ` Junio C Hamano

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:

  List information:

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

  git send-email \ \ \ \ \ \

* 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

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).