From: Stefan Beller <email@example.com> To: Michael Forney <firstname.lastname@example.org> Cc: git <email@example.com> Subject: Re: Confusing behavior with ignored submodules and `git commit -a` Date: Mon, 26 Nov 2018 16:03:06 -0800 Message-ID: <CAGZ79kax6NpHP-rouezE-A8a2jVN+sC1WnouFWDcaCqYWhs_9w@mail.gmail.com> (raw) In-Reply-To: <CAGw6cBvsiW7nwkJ_DBhXOYkgh7ba+rm+pwd4tOAt1ohRvcCY=A@mail.gmail.com> On Thu, Nov 15, 2018 at 4:31 PM Michael Forney <firstname.lastname@example.org> wrote: > > On 2018-11-15, Stefan Beller <email@example.com> wrote: > > On Thu, Nov 15, 2018 at 1:33 PM Michael Forney <firstname.lastname@example.org> wrote: > >> Well, currently the submodule config can be disabled in diff_flags by > >> setting override_submodule_config=1. However, I'm thinking it may be > >> simpler to selectively *enable* the submodule config in diff_flags > >> where it is needed instead of disabling it everywhere else (i.e. > >> use_submodule_config instead of override_submodule_config). > > > > This sounds like undoing the good(?) part of the series that introduced > > this regression, as before that we selectively loaded the submodule > > config, which lead to confusion when you forgot it. Selectively *enabling* > > the submodule config sounds like that state before? > > > > Or do we *only* talk about enabling the ignore flag, while loading the > > rest of the submodule config automatic? > > Yes, that is what I meant. I believe the automatic loading of > submodule config is the right thing to do, it just uncovered cases > where the current handling of override_submodule_config is not quite > sufficient. That sounds good. > > My suggestion of replacing override_submodule_config with > use_submodule_config is because it seems like there are fewer places > where we want to apply the ignore config than not. I think it should > only apply in diffs against the working tree and when staging changes > to the index (unless specified explicitly). The documentation just > mentions the "diff family", but all but one of the possible values for > submodule.<name>.ignore ("all") don't make sense unless comparing with > the working tree. This is also how show/log -p behaved in git <2.15. > So I think that clarifying that it is about modifications *to the > working tree* would be a good idea. > > >> I'm also starting to see why this is tricky. The only difference that > >> diff.c:run_diff_files sees between `git add inner` and `git add --all` > >> is whether the index entry matched the pathspec exactly or not. > > > > Unrelated to the trickiness, I think we'd need to document the behavior > > of the -a flag in git-add and git-commit better as adding the diff below > > will depart from the "all" rule again, which I thought was a strong > > motivator for Brandons series (IIRC). > > Can you explain what you mean by the "all" rule? -a as short for --all in git commit, and I presumed it to be '--all-content', but documentation tells me it's about files only, so there is no really an "all" rule, but rather me misunderstanding to what it applies.
next prev parent 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 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 [this message] 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: 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=CAGZ79kax6NpHP-rouezE-A8a2jVN+sC1WnouFWDcaCqYWhs_9w@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
firstname.lastname@example.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