On 19/03/12 21:43, Junio C Hamano wrote: > Andrew Sayers <andrew-git@xxxxxxxxxxxxxxx> writes: > >> On 18/03/12 18:50, Junio C Hamano wrote: >>> >>> ... but in short, it is not a problem we can solve >>> (nor we should be solving), as long as we have a reasonable migration plan >>> and if the user is locked out of that migration plan---whoever is doing >>> the locking-out is taking responsibility for these users who are out of >>> our reach. >> >> I take the point that distros have their own support infrastructure, so >> perhaps this would be a better example: >> >> Many administrators in corporate environments will install git from >> source, because they don't trust RPM/need some feature in the latest >> version/are just that way inclined. Having installed it, they tend to >> sit on that version for a few years ... > > The same response applies. These administrators are taking responsibility > for their users by making them out of our reach. > I'm not sure I follow. It sounds like you're saying we should avoid helping anyone that doesn't stick to our upgrade schedule, but that would mean it's redundant to add code at all - all the publicity this change has got means everyone close enough to the process has heard about it already. >> ... a >> slightly better solution: >> >> When a user upgrades to a mid- or post-change version of git, I think >> it's a good idea for them to be warned about the change of behaviour. >> But new users, and old users with new repositories, gain nothing from >> the little history lesson. > > You are right for new users, but are wrong for old users who aren't aware > of the switch-over, *and* are harmed by the switch-over. You're right that the solution I suggested would harm people who regularly create new repositories, but have written scripts that expect the old behaviour in those new repositories. The only solution that would completely avoid harming that small group would be to permanently make the default push.default "print a warning and give up" - otherwise you're just harming people with long schedules instead of those with short ones. - Andrew -- 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