On Tue, Dec 7, 2010 at 1:08 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Am 07.12.2010 21:31, schrieb Kevin Ballard: >> On Dec 7, 2010, at 4:15 AM, Ävar ArnfjÃrÅ Bjarmason 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. >> >> 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. > > 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? > 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. -- 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