On Dec 7, 2010, at 12:37 PM, Scott Kyle wrote: > On Tue, Dec 7, 2010 at 4:15 AM, Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: >> >> On Tue, Dec 7, 2010 at 00:22, Scott Kyle <scott@xxxxxxxxxx> wrote: >>> 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. >> >> 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. > > 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. 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-- 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