git diff --numstat <branch> always shows dirty submodules

git diff --numstat <branch> always shows dirty submodules

[Gelonida N]

Hi,

I recently started using submodules and they behave mostly as I like to.


Normally I use diff --numstat <branch>
to check quickly whether I am aligned with another branch or not.

The (for me) annoying feature of submodules is, that they are always
reported to be different due to files, which are not under git.


I type git diff --numstat master
I get
1       1       mysubmodule


Now I check the differences with git diff master mysubmodule
diff --git a/mysubmodule b/mysubmodule
index 1382b73..f4f1f1d 160000
--- a/mysubmodule
+++ b/mysubmodule
@@ -1 +1 @@
-Subproject commit xxxxxxxxx
+Subproject commit xxxxxxxxx-dirty

So the only difference (which I wasn't interested in) is, that the
submodule is dirty.


Is there any quick way flag / helper script / . . .
to show differences between two branches without raising the fact, that
submodules are dirty?

>From a user perspective I don't see why this is reported.
I am not being warned about dirty files in the top level repository

Re: git diff --numstat <branch> always shows dirty submodules

[Jens Lehmann]

Am 12.11.2011 14:29, schrieb Gelonida N:
> I recently started using submodules and they behave mostly as I like to.

Good to hear that.

> Normally I use diff --numstat<branch>
> to check quickly whether I am aligned with another branch or not.
>
> The (for me) annoying feature of submodules is, that they are always
> reported to be different due to files, which are not under git.
>
>
> I type git diff --numstat master
> I get
> 1       1       mysubmodule
>
>
> Now I check the differences with git diff master mysubmodule
> diff --git a/mysubmodule b/mysubmodule
> index 1382b73..f4f1f1d 160000
> --- a/mysubmodule
> +++ b/mysubmodule
> @@ -1 +1 @@
> -Subproject commit xxxxxxxxx
> +Subproject commit xxxxxxxxx-dirty
>
> So the only difference (which I wasn't interested in) is, that the
> submodule is dirty.
 >
> Is there any quick way flag / helper script / . . .
> to show differences between two branches without raising the fact, that
> submodules are dirty?

Yes, there is the "--ignore-submodules" command line option and the
diff.ignoreSubmodules (which can be set globally and/or per repo) and
submodule.<name.>ignore configuration settings. They can be set to
"untracked", "dirty" or "all" to control what you want to see.

Did you check areas in the Documentation where you did expect to find
them mentioned but they weren't? Then please say so that we can fix
that.

>> From a user perspective I don't see why this is reported.
> I am not being warned about dirty files in the top level repository

This is so you can't forget to add new files inside the submodule,
which can lead to breakage when other people clone the superproject
but won't get the new files from the submodule because you didn't
commit them there.

Re: git diff --numstat <branch> always shows dirty submodules

[Gelonida N]

Hi Jens,

Thanks a lot for your answer.

On 11/12/2011 09:02 PM, Jens Lehmann wrote:
> Am 12.11.2011 14:29, schrieb Gelonida N:
>> I recently started using submodules and they behave mostly as I like to.
>> Normally I use diff --numstat<branch>
>> to check quickly whether I am aligned with another branch or not.
>> . . . 
>> Is there any quick way flag / helper script / . . .
>> to show differences between two branches without raising the fact, that
>> submodules are dirty?
> 
> Yes, there is the "--ignore-submodules" command line option and the
> diff.ignoreSubmodules (which can be set globally and/or per repo) and
> submodule.<name.>ignore configuration settings. They can be set to
> "untracked", "dirty" or "all" to control what you want to see.
I tried this immediately and at works perfectly for git diff.
Please see also my comments at the end of this post

> 
> Did you check areas in the Documentation where you did expect to find
> them mentioned but they weren't? Then please say so that we can fix
> that.
> 

Apologies. My bad. I must have read the output of
git help diff
too quickly.
It is there plain as the day. :-(

>>> From a user perspective I don't see why this is reported.
>> I am not being warned about dirty files in the top level repository
> 
> This is so you can't forget to add new files inside the submodule,
> which can lead to breakage when other people clone the superproject
> but won't get the new files from the submodule because you didn't
> commit them there.

Well I wouldn't expect to find this kind of info (by default) in the
output of a git-diff.

If you git-diff two branches of a project without submodules it doesn't
tell you either, that you have untracked files in the repository.


I would have expected this kind of output just as result of
'git status'
(as it is already today)
#	modified:  submodule (untracked content)

Git status reports untracked files in the super project AND in it
reports, that there are untracked files in the submodule.
So this seems to be more consistent to me than the diff case.


On the other hand I would consider it usefult if git status could
optionally report the complete list of untracked files also for the
submodules
(So far I didn't search in depth  in doc whether there is a switch
for it.)


A first shot was reading the output of git help status:
>       If status.submodulesummary is set to a non zero number or true (identical to -1 or an unlimited number), the
>        submodule summary will be enabled for the long format and a summary of commits for modified submodules will
>        be shown (see --summary-limit option of git-submodule(1)).

I put thus following lines in .git/config of my repository
status]
    submodulesummary = true


 but the untracked files of my submodule were not reported. (will follow
the doc of git-submodule)



What is also confusing to me is, that the setting
diff.ignoreSubmodules is also being used by git status.

There seems to be no variable
status.ignoreSubmodules

So it seems impossible (without aliases) to
have git diff NOT report the untracked files,
but git status report them.

I guess I'll go for a solution with git aliases