git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Jeff King <peff@peff.net>, Brandon Williams <bmwill@google.com>, "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 0/3] Convert grep to recurse in-process
Date: Wed, 12 Jul 2017 11:17:17 -0700
Message-ID: <CAGZ79kbFpvzRHTK6KvWE399devPec+XSq_7V+roANbxbc29_-w@mail.gmail.com> (raw)
In-Reply-To: <20170712180923.GE93855@aiede.mtv.corp.google.com>

On Wed, Jul 12, 2017 at 11:09 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> Jeff King wrote:
>
>> I didn't follow the rest of the "struct repository" series closely, but
>> I don't feel like we ever reached a resolution on how config would be
>> handled. I notice that the in-process "ls-files" behaves differently
>> than the old one when config differs between the submodule and the
>> parent repository. As we convert more commands (that use more config)
>> this will become more likely to be noticed by somebody.
>>
>> Do we have a plan for dealing with this? Is our solution just "recursed
>> operations always respect the parent config, deal with it"?
>
> For settings like branch.<name>.remote, I don't think anyone would
> disagree that the right thing to do is to use the per-repository
> config of the submodule.  The repository object is already able to
> handle per-repository config, so this just involves callers being
> careful not to cache values locally in a way that conflates
> repositories.  It should be pretty straightforward (for commands like
> "git fetch --recurse-submodules", for example).
>
> For settings like grep.patternType, on the other hand, it would be
> very strange for the behavior to change when grep crosses the
> submodule boundary.

That is because this option relates to the input given.
Other options relate to the items to be processed, such as grep.color.*
which I would not find strange if they were respected in the submodule.

> So I think using the parent project config is the
> right thing to do and the old behavior was simply wrong.  In other
> words, I don't think this is so much a case of "deal with it" as
> "sorry we got the behavior so wrong before --- we've finally fixed it
> now".

In an ideal world we should pay partial attention to the config
in the submodule, and for each config key we'd have to determine
if it rather relates to the general runtime (grep.threads), the command
line options (grep.patternType) or to the specific content inside the repo
(coloring, whether we show the line number).

For now and in reality we can ignore the content specific settings
and claim that any setting here is related to runtime and command line
options, both of which a user may expect the superproject to win in
case of differing configurations.

Thanks,
Stefan

  reply index

Thread overview: 48+ messages in thread (expand / mbox.gz / Atom feed / [top])
2017-07-11 22:04 Brandon Williams
2017-07-11 22:04 ` [PATCH 1/3] repo_read_index: don't discard the index Brandon Williams
2017-07-11 23:51   ` Jonathan Nieder
2017-07-12 17:27     ` Brandon Williams
2017-07-11 23:58   ` Stefan Beller
2017-07-12 17:23     ` Brandon Williams
2017-07-11 22:04 ` [PATCH 2/3] setup: have the_repository use the_index Brandon Williams
2017-07-12  0:00   ` Jonathan Nieder
2017-07-12  0:07     ` Stefan Beller
2017-07-12 17:30     ` Brandon Williams
2017-07-12  0:11   ` Junio C Hamano
2017-07-12 18:01     ` Brandon Williams
2017-07-12 20:38       ` Junio C Hamano
2017-07-12 21:33         ` Jonathan Nieder
2017-07-12 21:40           ` Junio C Hamano
2017-07-18 21:34             ` Junio C Hamano
2017-07-11 22:04 ` [PATCH 3/3] grep: recurse in-process using 'struct repository' Brandon Williams
2017-07-11 22:44   ` Jacob Keller
2017-07-12 18:54     ` Brandon Williams
2017-07-12  0:04   ` Stefan Beller
2017-07-12 18:56     ` Brandon Williams
2017-07-12  0:25   ` Jonathan Nieder
2017-07-12 18:49     ` Brandon Williams
2017-07-12  7:42 ` [PATCH 0/3] Convert grep to recurse in-process Jeff King
2017-07-12 18:06   ` Brandon Williams
2017-07-12 18:17     ` Jeff King
2017-07-12 18:24       ` Jonathan Nieder
2017-07-12 18:33         ` Jeff King
2017-07-12 18:09   ` Jonathan Nieder
2017-07-12 18:17     ` Stefan Beller [this message]
2017-07-12 18:27     ` Jeff King
2017-07-14 22:28 ` [PATCH v2 " Brandon Williams
2017-07-14 22:28   ` [PATCH v2 1/3] repo_read_index: don't discard the index Brandon Williams
2017-07-14 22:28   ` [PATCH v2 2/3] repository: have the_repository use the_index Brandon Williams
2017-07-14 22:28   ` [PATCH v2 3/3] grep: recurse in-process using 'struct repository' Brandon Williams
2017-07-18 19:05   ` [PATCH v3 00/10] Convert grep to recurse in-process Brandon Williams
2017-07-18 19:05     ` [PATCH v3 01/10] repo_read_index: don't discard the index Brandon Williams
2017-07-18 19:05     ` [PATCH v3 02/10] repository: have the_repository use the_index Brandon Williams
2017-07-18 19:05     ` [PATCH v3 03/10] cache.h: add GITMODULES_FILE macro Brandon Williams
2017-07-18 19:05     ` [PATCH v3 04/10] config: add config_from_gitmodules Brandon Williams
2017-07-18 19:05     ` [PATCH v3 05/10] submodule: remove submodule.fetchjobs from submodule-config parsing Brandon Williams
2017-07-18 19:05     ` [PATCH v3 06/10] submodule: remove fetch.recursesubmodules " Brandon Williams
2017-07-18 19:05     ` [PATCH v3 07/10] submodule: check for unstaged .gitmodules outside of config " Brandon Williams
2017-07-18 19:05     ` [PATCH v3 08/10] submodule: check for unmerged " Brandon Williams
2017-07-18 19:05     ` [PATCH v3 09/10] submodule: merge repo_read_gitmodules and gitmodules_config Brandon Williams
2017-07-18 19:05     ` [PATCH v3 10/10] grep: recurse in-process using 'struct repository' Brandon Williams
2017-07-18 19:36     ` [PATCH v3 00/10] Convert grep to recurse in-process Junio C Hamano
2017-07-18 20:06       ` Brandon Williams

Reply instructions:

You may reply publically 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 to all the recipients using the --to, --cc,
  and --in-reply-to switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGZ79kbFpvzRHTK6KvWE399devPec+XSq_7V+roANbxbc29_-w@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox