diff-index does not consider a removed submodule to be staged with --ignore-submodules

Daniel Hahler· Sep 20, 2014, 16:20 UTC · lore

After staging the removal of a submodule, diff-index does not consider this when "--ignore-submodules" is being used:

    # In a repository with submodule "sm":
    % git rm --cached sm
    % git diff-index --cached --quiet --ignore-submodules HEAD
    % echo $?
    0
    % git status
    On branch master
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)

        deleted:    sm

"git status --ignore-submodules" behaves the same.

>From the man page of "--ignore-submodules" it looks like the option is meant to prevent scanning of submodules itself, but in this case the main repository is affected.

This command is used by zsh's vcs_info module (in Functions/VCS_Info/Backends/VCS_INFO_get_data_git):

    if (( querystaged )) ; then
        if ${vcs_comm[cmd]} rev-parse --quiet --verify HEAD &> /dev/null ; then
            ${vcs_comm[cmd]} diff-index --cached --quiet --ignore-submodules HEAD 2> /dev/null
            (( $? && $? != 128 )) && gitstaged=1

Is this a bug/oversight in Git or by design? Is there a better way to detect if there are any staged changes?

Regards, Daniel.

-- 
http://daniel.hahler.de/

Jens Lehmann· Sep 21, 2014, 21:36 UTC · re: Daniel Hahler · lore

Re: diff-index does not consider a removed submodule to be staged with --ignore-submodules

Am 20.09.2014 um 18:20 schrieb Daniel Hahler:

Show 17 quoted lines

> After staging the removal of a submodule, diff-index does not consider this when "--ignore-submodules" is being used:
>
>      # In a repository with submodule "sm":
>      % git rm --cached sm
>      % git diff-index --cached --quiet --ignore-submodules HEAD
>      % echo $?
>      0
>      % git status
>      On branch master
>      Changes to be committed:
>        (use "git reset HEAD <file>..." to unstage)
>
>          deleted:    sm
>
> "git status --ignore-submodules" behaves the same.
>
>>From the man page of "--ignore-submodules" it looks like the option is meant to prevent scanning of submodules itself, but in this case the main repository is affected.

Sorry, but I don't know what man page you are talking about here ...

Show 9 quoted lines

> This command is used by zsh's vcs_info module (in Functions/VCS_Info/Backends/VCS_INFO_get_data_git):
>
>      if (( querystaged )) ; then
>          if ${vcs_comm[cmd]} rev-parse --quiet --verify HEAD &> /dev/null ; then
>              ${vcs_comm[cmd]} diff-index --cached --quiet --ignore-submodules HEAD 2> /dev/null
>              (( $? && $? != 128 )) && gitstaged=1
>
> Is this a bug/oversight in Git or by design?
> Is there a better way to detect if there are any staged changes?

It might be that --ignore-submodules=dirty is what you want. It will report changes in the committed submodule SHA-1, added and removed submodules but won't care about any modifications inside the submodule.