From: Jens Lehmann <Jens.Lehmann@web.de>
To: Daniel Hahler <genml+git-2014@thequod.de>, git@vger.kernel.org
Subject: Re: diff-index does not consider a removed submodule to be staged with --ignore-submodules
Date: Sun, 21 Sep 2014 23:36:10 +0200 [thread overview]
Message-ID: <541F44CA.7080403@web.de> (raw)
In-Reply-To: <541DA95A.2030407@thequod.de>
Am 20.09.2014 um 18:20 schrieb Daniel Hahler:
> 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 ...
> 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.
prev parent reply other threads:[~2014-09-21 21:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-20 16:20 diff-index does not consider a removed submodule to be staged with --ignore-submodules Daniel Hahler
2014-09-21 21:36 ` Jens Lehmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=541F44CA.7080403@web.de \
--to=jens.lehmann@web.de \
--cc=genml+git-2014@thequod.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).