__git_ps1 not showing submodule dirty state

__git_ps1 not showing submodule dirty state

[Kevin Ballard]

Why does the __git_ps1 function in git-completion.bash explicitly ignore submodules when showing the GIT_PS1_SHOWDIRTYSTATE status? The most common issue with my current repository is not realizing when submodules need to be updated because I blindly trust my prompt to tell me when I have dirty state.

-Kevin Ballard

Re: __git_ps1 not showing submodule dirty state

[Johan Herland]

On Wednesday 30 December 2009, Kevin Ballard wrote:
> Why does the __git_ps1 function in git-completion.bash explicitly ignore
>  submodules when showing the GIT_PS1_SHOWDIRTYSTATE status? The most
>  common issue with my current repository is not realizing when submodules
>  need to be updated because I blindly trust my prompt to tell me when I
>  have dirty state.

According to git blame, it has been there since GIT_PS1_SHOWDIRTYSTATE was 
introduced in 738a94a... by Thomas Rast (CCed), but the commit message does 
not say why submodules are explicitly ignored.

FWIW, I agree with Kevin, and would like changed submodules to be included 
in the status.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

[PATCH] bash completion: factor submodules into dirty state

[Thomas Rast]

In the implementation of GIT_PS1_SHOWDIRTYSTATE in 738a94a (bash:
offer to show (un)staged changes, 2009-02-03), I cut&pasted the
git-diff invocations from dirty-worktree checks elsewhere, carrying
along the --ignore-submodules option.

As pointed out by Kevin Ballard, this doesn't really make sense: to
the _user_, a changed submodule counts towards uncommitted changes.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

Johan Herland wrote:
> On Wednesday 30 December 2009, Kevin Ballard wrote:
> > Why does the __git_ps1 function in git-completion.bash explicitly ignore
> >  submodules when showing the GIT_PS1_SHOWDIRTYSTATE status? The most
> >  common issue with my current repository is not realizing when submodules
> >  need to be updated because I blindly trust my prompt to tell me when I
> >  have dirty state.
> 
> According to git blame, it has been there since GIT_PS1_SHOWDIRTYSTATE was 
> introduced in 738a94a... by Thomas Rast (CCed), but the commit message does 
> not say why submodules are explicitly ignored.
> 
> FWIW, I agree with Kevin, and would like changed submodules to be included 
> in the status.

No good reason; I really do remember cut&pasting the checks, though
I'm not sure from where.

I don't really use submodules, so I'll just trust your judgements that
it's better to factor them into the status.


 contrib/completion/git-completion.bash |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c65462c..a455fe8 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -142,11 +142,9 @@ __git_ps1 ()
 		elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
 			if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
 				if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
-					git diff --no-ext-diff --ignore-submodules \
-						--quiet --exit-code || w="*"
+					git diff --no-ext-diff --quiet --exit-code || w="*"
 					if git rev-parse --quiet --verify HEAD >/dev/null; then
-						git diff-index --cached --quiet \
-							--ignore-submodules HEAD -- || i="+"
+						git diff-index --cached --quiet HEAD -- || i="+"
 					else
 						i="#"
 					fi
-- 
1.6.6.337.g4932e