Jonathan Nieder wrote: > Ramkumar Ramachandra wrote: >> Junio C Hamano wrote: >>> Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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. -- 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