For those who often work on repositories with submodules, the dirty
indicator for unstaged changes will almost always show because development
is simultaneously happening on those submodules. The config option
diff.ignoreSubmodules is not appropriate for this use because it has larger
implications.

Signed-off-by: Scott Kyle <scott@appden.com>
---
 contrib/completion/git-completion.bash |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 604fa79..539bcb1 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -37,7 +37,9 @@
 #       value, unstaged (*) and staged (+) changes will be shown next
 #       to the branch name.  You can configure this per-repository
 #       with the bash.showDirtyState variable, which defaults to true
-#       once GIT_PS1_SHOWDIRTYSTATE is enabled.
+#       once GIT_PS1_SHOWDIRTYSTATE is enabled.  You can also set
+#       GIT_PS1_IGNORESUBMODULES to a value that git diff understands
+#       to adjust the behavior of the dirty state indicator.
 #
 #       You can also see if currently something is stashed, by setting
 #       GIT_PS1_SHOWSTASHSTATE to a nonempty value. If something is stashed,
@@ -286,7 +288,8 @@ __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 --quiet --exit-code || w="*"
+					local ignore_submodules=${GIT_PS1_IGNORESUBMODULES+"--ignore-submodules=$GIT_PS1_IGNORESUBMODULES"}
+					git diff $ignore_submodules --no-ext-diff --quiet --exit-code || w="*"
 					if git rev-parse --quiet --verify HEAD >/dev/null; then
 						git diff-index --cached --quiet HEAD -- || i="+"
 					else
-- 
1.7.3.3.574.g98527

--

[ message continues ]

Hi Scott,



git diff "understands" a lot of things, therefore I'd like to be a bit
more specific here by mentioning the --ignore-submodules= option:

+#       once GIT_PS1_SHOWDIRTYSTATE is enabled.  You can also set
+#       GIT_PS1_IGNORESUBMODULES to a value that git diff
+#       --ignore-submodules= understands to adjust the behavior of the
+#       dirty state indicator.

But it might be just me being unfamiliar with submodules.  Otherwise
--

[ message continues ]

Wouldn't it be a lot better to instead add support for showing
submodule dirtyness as distinct from the main tree's dirtyness? Then
you could easily spot if you had either your tree / submodule tree
changes, without just ignoring them.
--

[ message continues ]

[sorry for the duplicate email, my original was rejected from the list]

On Tue, Dec 7, 2010 at 4:15 AM, Ævar Arnfjörð Bjarmason

I considered that, but thought it to be a rather disruptive change,
and one that conceptually didn't work.  The way I see it, either
somebody thinks of their repo as dirty when the submodules are dirty,
or not. And I think since this behavior has perpetuated for so long,
most users are content with how it currently works.  I, however, was
not, and so that is why I added an option for people like me.

Scott Kyle

http://appden.com
http://github.com/appden
http://twitter.com/appden
--

[ message continues ]

The big win for such a change, from my perspective, is it tells me if I need
to do a `git submodule update --recursive`, or if I actually have dirty changes.
Because of that, if nobody else picks this up, I'll probably write a patch
to introduce such a config at some point in the future. But as I said before,
that's something that can be done later and doesn't need to affect this patch.

-Kevin Ballard--

[ message continues ]

Yeah. I didn't mean to imply that the current patch wasn't useful. It
also is for people like Scott that just want to ignore submodules, but
most of us care about them being dirty.

So having support for both (ignoring and tracking) in __git_ps1 would
be great. It would be very useful if you or someone else could pick
this up.
--

[ message continues ]

That sounds like a good idea, but it doesn't necessarily have to come with
this patch. Scott's use case here is he has a submodule that is _always_ dirty,
and he simply doesn't want to see that stuff in the PS1. Having an option to
show it separately would be very useful for me, but should perhaps be written
as a separate patch.

-Kevin Ballard--

[ message continues ]

I'm not sure if I understand your case correctly, but if there is only one
submodule that is always dirty and everybody knows that but nobody cares,
won't it make sense to change the "submodule.<name>.ignore" config option
for that peculiar submodule via .git/config or .gitmodules?
--

[ message continues ]

If I set the "submodule.<name>.ignore" then diffing around inside my
history will not show the changes to that particular submodule.  That
is what I meant by diff.ignoreSubmodules having larger implications.
--

[ message continues ]

Ah, seems I misunderstood your submodule being dirty as modified or
untracked files being present in it's work tree. But your submodules
HEAD seems to differ from the commit recorded in the superproject,
and then of course "submodule.<name>.ignore=dirty" won't help you.
--

[ message continues ]

Even if you set it to "dirty"?
--

[ message continues ]

Setting it to "dirty" is far less disruptive, you're right, but that
wouldn't do me much good since my submodules are often on different
branches while developing.
--

[ message continues ]

Ah, I see now.  How about something like this?  Untested, just a
vague sketch to show the idea.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 Documentation/config.txt       |    4 +++-
 Documentation/diff-options.txt |    7 +++++--
 Documentation/git-status.txt   |   14 ++------------
 Documentation/gitmodules.txt   |    4 +++-
 diff-lib.c                     |    3 ++-
 diff.h                         |    3 ++-
 submodule.c                    |    4 ++++
 7 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0f85793..b93e92b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1810,7 +1810,9 @@ submodule.<name>.update::
 submodule.<name>.ignore::
 	Defines under what circumstances "git status" and the diff family show
 	a submodule as modified. When set to "all", it will never be considered
-	modified, "dirty" will ignore all changes to the submodules work tree and
+	modified, "worktree" will ignore all changes in the work tree not
+	registered in the superproject index, "dirty" will ignore all changes
+	to the submodules work tree and
 	takes only differences between the HEAD of the submodule and the commit
 	recorded in the superproject into account. "untracked" will additionally
 	let submodules with modified tracked files in their work tree show up.
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index f3e9538..93fe084 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -360,7 +360,8 @@ endif::git-format-patch[]
 
 --ignore-submodules[=<when>]::
 	Ignore changes to submodules in the diff generation. <when> can be
-	either "none", "untracked", "dirty" or "all", which is the default
+	either "none", "untracked", "dirty", "worktree", or "all", which is
+	the default.
 	Using "none" will consider the submodule modified when it either contains
 	untracked or modified files or its HEAD differs from the commit ...
[ message continues ]

Me thinks your proposal of a new "worktree" option makes sense. Let's
hear what Scott says ...
--

[ message continues ]

I mostly really like how 'worktree' can let me focus in on only the
submodules I care about.  The drawback is that git status would no
longer list my true status.  I know that may sound hypocritical, but I
intended for this patch to only affect my PS1.  At the same time, I
would like to see the 'worktree' patch taken, regardless of whether
you guys find mine useful.
--

[ message continues ]