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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 7, 2010 at 21:41, Kevin Ballard <kevin@xxxxxx> wrote:
> 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.

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.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]