Re: Why does 'submodule add' stage the relevant portions?

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mar 25, 2013, 18:27 UTC
Message-ID: <CALkWK0kx_uQy-97nByNXBOU4UruhvdjOeXCpKHR9mNUQHs5o=A@mail.gmail.com>
In-Reply-To: <20130325182023.GA1414@google.com>

Jonathan Nieder wrote:

Show 22 quoted lines

> Ramkumar Ramachandra wrote:
>> Junio C Hamano wrote:
>>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>>>> Git 2.0 is coming soon, so I'm excited about breaking a lot of
>>>> backward compatibility ;)
>>>
>>> Don't.
>>
>> push.default is the necessary exception?
>
> A while ago there was a discussion of changes of the "If we were
> starting over today, it would be obvious we should have made it work
> the other way" kind and potential transition plans for them leading up
> to 2.0.  It's way too late to throw new breakage in.
>
> More generally, it doesn't make a lot of sense to save thinking about
> such questions for the last minute before a new major release.  If an
> important change will require breaking compatibility and can only be
> done using a painful 5-year transition, start today (and send patches
> to the ML when an appropriate quiet moment comes to get review) so the
> 5-year counter can start ticking.

I agree that big important changes that break backward compatibility (like adding generation numbers to commit objects) will require this kind of time and effort to stabilize. Does a saner push.default value, or even tweaking the output of 'git status' to show what 'git status -sb' shows now (git status is porcelain, and no person in the right mind will write a script to parse it), require this? I'm talking about slightly better defaults at the porcelain level, at most.