Re: diff-index does not consider a removed submodule to be staged with --ignore-submodules
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Sep 21, 2014, 21:36 UTC
- Message-ID
- <541F44CA.7080403@web.de>
- In-Reply-To
- <541DA95A.2030407@thequod.de>
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.