list mirror (unofficial, one of many)
 help / color / Atom feed
From: Stefan Beller <>
To: Michael Forney <>
Cc: git <>, Brandon Williams <>
Subject: Re: Confusing behavior with ignored submodules and `git commit -a`
Date: Thu, 15 Nov 2018 12:03:06 -0800
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Nov 14, 2018 at 10:05 PM Michael Forney <> wrote:
> +bmwill
> On 2018-11-14, Michael Forney <> wrote:
> > On 2018-10-25, Stefan Beller <> wrote:
> >> I guess reverting that commit is not a good idea now, as
> >> I would expect something to break.
> >>
> >> Maybe looking through the series 614ea03a71
> >> (Merge branch 'bw/submodule-config-cleanup', 2017-08-26)
> >> to understand why it happened in the context would be a good start.
> >
> > Thanks, that's a good idea. I'll take a look through that series.
> Interesting. If I build git from master after reverting 55568086, I do
> indeed observe the issue it claims to fix (unable to add ignored
> submodules). However, if I build from 9ef23f91fc (the immediate parent
> of 55568086), I do not see the issue.
> Investigating this further, it seems that 55568086 addresses an issue
> that does not appear until later on in the series in ff6f1f564c
> (submodule-config: lazy-load a repository's .gitmodules file). Perhaps
> this was a result of reordering commits during a rebase. In other
> words, I get correct behavior until 55568086, and in
> 55568086..ff6f1f564c^ if I revert 55568086.
> Looking at ff6f1f564c, I don't really see anything that might be
> related to git-add, git-reset, or git-diff, so I'm guessing that this
> only worked before because the submodule config wasn't getting loaded
> during `git add` or `git reset`. Now that the config is loaded
> automatically, submodule.<name>.ignore started taking effect where it
> shouldn't.
> Unfortunately, this doesn't really get me much closer to finding a fix.

Maybe selectively unloading or overwriting the config?

Or we can change is_submodule_ignored() in diff.c
to be only applied selectively whether we are running the
right command? For this approach we'd have to figure out the
set of commands to which the ignore config should apply or
not (and come up with a more concise documentation then)

This approach sounds appealing to me as it would cover
new commands as well and we'd only have a central point
where the decision for ignoring is made.


  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-17  3:57 Michael Forney
2018-10-25 18:03 ` Michael Forney
2018-10-25 18:26   ` Stefan Beller
2018-11-15  5:12     ` Michael Forney
2018-11-15  6:05       ` Michael Forney
2018-11-15 20:03         ` Stefan Beller [this message]
2018-11-15 21:33           ` Michael Forney
2018-11-15 21:53             ` Michael Forney
2018-11-15 22:23             ` Stefan Beller
2018-11-16  0:31               ` Michael Forney
2018-11-27  0:03                 ` Stefan Beller
2018-11-15 19:39       ` Stefan Beller

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:

  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 list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	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:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox