Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>> Junio C Hamano wrote:
>>> Ramkumar Ramachandra <> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to