From: Claus Schneider <claus.schneider@eficode.com>
Date: Thu, 13 Nov 2025 12:51:53 GMT
Subject: Re: [PATCH 0/5] git-add : Respect submodule ignore=all and only add changes with --force
Message-ID: <CA+GP4boOQ0YfKHOup4qxA2hiwA63d=61LF7jdD-=bHGTw1CfxA@mail.gmail.com>
In-Reply-To: <63d07c3c-ac4b-4ef9-ad90-d79f00cc7ca9@gmail.com>

Thanks for the feedback and suggestions.

I have now implemented the --include-ignored-submodules option instead
of --force.
I have also extended the commit messages with more reasoning.

? Is it best to have a single commit with everything or a set of
commit for each part of the solution

? How do I update the patches with the modifications accordingly (
from GitGadget PR with a new /submit ) ?

Thanks in advance
Claus Schneider

On Fri, Oct 24, 2025 at 3:55 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> Hi Claus
>
> On 19/10/2025 22:39, Claus Schneider wrote:
> > On Sun, Oct 19, 2025, 17:34 Phillip Wood <phillip.wood123@gmail.com
> > <mailto:phillip.wood123@gmail.com>> wrote:
> >
> >> I was curious why, when "git add" uses the same machinery as "git diff"
> >> to figure out which paths need updating, it behaves differently. It
> >> turns out that add_files_to_cache() contains
> >>
> >>           rev.diffopt.flags.override_submodule_config = 1;
> >>
> >> which makes "git add" ignore "submodule.<name>.ignore". Tracing the
> >> history of this line, it originates from 5556808690e (add, reset: ensure
> >> submodules can be added or reset, 2017-07-25) which made a deliberate
> >> choice for both "git add" and "git reset" not to behave like "git diff".
>
> > Thank you for your feedback and for investigating this. I was not aware > of the setting that causes `add` and `reset` to override submodule
> > configuration, and I will need to look into `reset` further.
>
> You should mention the commit that added the current behavior and the
> reason it was added in the commit message where you change the behavior.
>
> > I understand the problematic aspect of not being able to add an update
> > of a submodule reference, which likely led to the overwrite setting.
> > From a Git developer's perspective, always adding it might have seemed
> > like the simplest approach.
> >
> > However, from an end-user perspective, it's not logical for `status` to
> > show nothing while `add` has an effect.
>
> I'm quite sympathetic to this view, I think you should explain this in the
> commit message where you change the behavior and see what others think.
>
> > A more intuitive workflow would
> > align with how ignored files are handled even though it is already tracked.
>
> As I said before do not think conflating ignoring changes to tracked files
> with ignoring files is a good idea. The two are fundamentally different
> because ignored files are not tracked. I would suggest adding a new option
> such as "--include-ignored-submodules" instead of piggybacking on "--force".
> Using a different option also means that user's will not accidentally stage
> ignored files when they're trying to stage a submodule whose changes are
> normally ignored.
>
> > My patch implements what I believe should have been in the first place.
> > My implementation still needs the `overwrite=1` set in order to get the
> > diff files list so I can 'operate' on it and make the `--force` logic
> > like the ignore files.
>
> Oh, you're right, if we want to print a warning we will need to keep
> overriding the submodule config.
>
> Hopefully someone with more experience of submodules will be able to review
> the code soon.
>
> Thanks
>
> Phillip