On 19 March 2012 22:43, Junio C Hamano <gitster@xxxxxxxxx> 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. > >> ... 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. What is your definition of "harmed" in this case? I do not see how a change like this could cause harm. I can see how it could cause disharmony, but that is not the same. I thought the worse case here is minor inconvenience, not data loss or anything else that is obviously harmful. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- 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