> > For some reason, the
> > `git add .` is adding the ignored submodule to the index.
> The ignore setting is documented to only affect diff output
> (including what checkout, commit and status show as modified).
> While I agree that this behavior is confusing for Sergey and
> not optimal for the floating branch model he uses, git is
> currently doing exactly what it should. And for people using
> the ignore setting to not having to stat submodules with huge
> and/or many files that behavior is what they want: don't bother
> me with what changed, but commit what I did change on purpose.
> We may have to rethink what should happen for users of the
> floating branch model though.

I totally see what's happening here and indeed current logic of `git
add .` agree is correct from how it was designed to. I could also see
why it might be useful to keep `git add .` and `git commit .` not to
respect submodule ignore flag. The only confusing thing here is that
if i stage changed submodule with this command i wouldn't see this
submodule in "changes to be committed" wen doing a commit.

So seems it's just matter of better communication of what's gonna to
be committed in "changes to be committed" section? Or maybe even make
it so `git status` will show staged changes from submdules hash
regardless ignore flag? Just an ideas how to make communication what's
going on a bit better :)

And for sure don't think suppressing stuff from git show is a nice
idea (if i understand your proposal f making submodule ignore option
affect on other commands).

With best regards, Sergey Sharybin
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to