After thinking some time about peoples expectations and troubles
with the recursive scanning of submodules, I came up with this:
What about expanding the "--ignore-submodules" option of the git diff
family with three parameters:
--ignore-submodules=all : Same behavior as "--ignore-submodules",
submodules show never up as modified.
--ignore-submodules=untracked : Don't consider submodules as modified
when they only contain untracked files, but do if the commits in the
superproject are different or tracked content is modified.
--ignore-submodules=dirty : Don't consider submodules as modified
when their work tree is dirty, no matter why. This is the pre 1.7.0
behavior and doesn't recurse into submodules at all.
The first patch is just a resend of a test case rename, the second
contains the implementation.
To make that more useful the default could be controlled by the
.git/config or .gitmodules file. So you could have two submodules:
[submodule "sub1"]
path = sub1
url = /home/me/sub1.git/
ignore = dirty
[submodule "sub2"]
path = sub2
url = /home/me/sub2.git/
ignore = untracked
Where sub1 will not be scanned for work tree modifications by "git
diff" and "git status" and for sub2 any untracked files inside the
submodule will be ignored. And then "git status" should learn the
"--ignore-submodule" option too. With a fourth parameter "none" it
would be possible to override the defaults from the configuration
anyway you want.
Opinions?
Jens Lehmann (2):
git diff: rename test that had a conflicting name
Add optional parameters to the diff option "--ignore-submodules"
Documentation/diff-options.txt | 10 ++-
diff-lib.c | 1 +
diff.c | 11 +++-
diff.h | 1 +
t/t4027-diff-submodule.sh | 20 ++++-
...submodule.sh => t4041-diff-submodule-option.sh} | 81 ++++++++++++++++++++
6 files changed, 118 insertions(+), 6 deletions(-)
rename t/{t4041-diff-submodule.sh => t4041-diff-submodule-option.sh} (74%)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html