Subject: Re: [PATCH] completion: Add PS1 configuration for submodules

From: Jens Lehmann <[email-masked]>
Date: Tue, 07 Dec 2010 22:28:28 +0100

Am 07.12.2010 22:17, schrieb Scott Kyle:
> On Tue, Dec 7, 2010 at 1:08 PM, Jens Lehmann <[email-masked]> 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 <[email-masked]> 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.

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.