git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Greg Hurrell <greg@hurrell.net>,
	git@vger.kernel.org,
	"Brian M. Carlson" <sandals@crustytoothpaste.net>
Subject: Re: git-checkout doesn't seem to respect config from include.path
Date: Thu, 03 Feb 2022 10:07:45 -0800	[thread overview]
Message-ID: <xmqq1r0jx1qm.fsf@gitster.g> (raw)
In-Reply-To: <0b8222c2-7337-7e8f-33d1-7926462daac1@gmail.com> (Phillip Wood's message of "Thu, 3 Feb 2022 15:54:23 +0000")

Phillip Wood <phillip.wood123@gmail.com> writes:

> ... What we really want in this case is to
> store the string value for each config option as we read each config
> source and then parse those values at the end, unfortunately I think
> that would break multi-valued config keys.

Thanks for raising, and looking into, the issue.

While the original "callback functions are called for each and every
configuration item defined in the files and it is the responsibility
for these callback functions to implement the semantics like the
last one wins" design that uses git_config() makes it harder, but I
think we are already halfway there, with the more recent API update
in 2014 (!) that allows config_get_value() to go directly get a
value given a key without writing callback functions.

I think builtin/add.c predates the configset API work (of course, it
is natural that we can "git add" way before 2014), and mostly uses
git_config(add_config) callback as a way to parse its configuration,
because it needs to tell other subsystems (like diff, merge, etc.)
that are even older to pay attention to the configuration variables
they care about.

So it may be a major surgery to switch to the newer
config_get_value() API.

For a "last one wins" variable, config_get_value() will only look at
the last item, so any garbage value Git does not recognize would not
trigger a fatal error.

Such an update is both good and bad.  Surely it makes the scenario
that triggered this discussion more pleasant by not dying, but it
makes it too pleasant by not even giving the user a chance to notice
a possible typo.

A incremental improvement that we can immediately make is probably
to teach the current xdiff-interface.c::git_xmerge_config() parser
to react to an unknown value differently.  It should not die() but
just ignore the unknown value, and issue a warning.  This should be
doable with minimum impact to the code.

Completely untested.  The first test that would be interesting to
run is how many tests this changes breaks to gauge how good test
coverage we have ;-)

 xdiff-interface.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git c/xdiff-interface.c w/xdiff-interface.c
index 2e3a5a2943..523b04960a 100644
--- c/xdiff-interface.c
+++ w/xdiff-interface.c
@@ -322,8 +322,8 @@ int git_xmerge_config(const char *var, const char *value, void *cb)
 		 * git-completion.bash when you add new merge config
 		 */
 		else
-			die("unknown style '%s' given for '%s'",
-			    value, var);
+			warning("ignored unknown style '%s' given for '%s'",
+				value, var);
 		return 0;
 	}
 	return git_default_config(var, value, cb);

  parent reply	other threads:[~2022-02-03 18:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02 16:04 git-checkout doesn't seem to respect config from include.path Greg Hurrell
2022-02-02 22:57 ` brian m. carlson
2022-02-03  7:48   ` Greg Hurrell
2022-02-03 15:54 ` Phillip Wood
2022-02-03 17:39   ` Greg Hurrell
2022-02-03 17:42     ` Greg Hurrell
2022-02-07 14:05     ` Phillip Wood
2022-02-03 18:07   ` Junio C Hamano [this message]
2022-02-07 14:01     ` Phillip Wood
2022-02-07 23:50       ` 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:
  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=xmqq1r0jx1qm.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=greg@hurrell.net \
    --cc=phillip.wood123@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    /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).