Re: [PATCH] completion: Add PS1 configuration for submodules
- From
Kevin Ballard <kevin@sb.org>
- Date
- Dec 7, 2010, 20:41 UTC
- Message-ID
- <4F33DA75-D095-415D-99F8-5236D6F93EE1@sb.org>
- In-Reply-To
- <AANLkTinuD2ze_mn5QMLqFaoftwZvTsz-DKv1ojAizg7P@mail.gmail.com>
On Dec 7, 2010, at 12:37 PM, Scott Kyle wrote:
Show 21 quoted lines
> On Tue, Dec 7, 2010 at 4:15 AM, Ævar Arnfjörð Bjarmason > <avarab@gmail.com> wrote: >> >> On Tue, Dec 7, 2010 at 00:22, Scott Kyle <scott@appden.com> 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