On 9 March 2012 06:38, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> I just dug it up; start from here: >> >> http://thread.gmane.org/gmane.comp.version-control.git/123350/focus=123541 >> >> read on a few messages downthread, and then jump to the other thread >> Nana points at in the above message. >> >> In short, we started warning that we _might_ change the default >> someday, without having a clear concensus or plan, that ended up >> confusing and annoying users without giving them anything good, >> other than awareness that such a feature is _available_. >> >> So no, the conversation did not decide if changing the default was >> warranted or not. It just confirmed that we weren't anywhere close >> to deciding back then. > > I think MJG's message (the second on in the "git push origin error" > thread) is probably what we would need to repeat, and this time more > strongly to squelch the opposition from old timers, if somebody > wants to resurrect the "warn until you set the default explicitly, > intending to change the default in the future" patch. And this time > around, the plan to change the default should be more concrete with > specific date, e.g. "Starting from April 1st, 2013". > > I was in the "keep the default to matching, so that nobody among > existing 47 million users would be annoyed" camp (back then we > probably didn't have 47 million users, but that is besides the > point) and I still am, but notice that I was defending the argument > by the "let's be ( (new user) friendly )" camp in that thread. And > without much fire-support from those who were vocal about it. > > Re-reading the thread made me sick. > > I wish I had enough energy remaining to say "Let's try one more > time, and hope that people from the 'let's change the default' camp > will behave much better than the last time", but I do not have high > hopes, after having been burned once already with exactly the same > issue. I think I read all the relevant mails, and I have a thought concerning what I see to be the class of the problem here: the general question of "how do you change default behavior if it turns out that the original choice was inappropriate". It seems to me you can think of solutions to that problem in general without considering the subject of this thread. A possible solution might be to give config files a "format version" of their own. They already contain a repository format version number, so add a new variable "ConfigVersionLevel". Alongside that you might introduce a policy of having new git "fill in" the defaults missing from the config file whenever it operates, so that people can explicitly view then all at once. Then if the defaults change in the future an old repo will continue to work as it did before. This alone would allow you to change the defaults for existing configurable behavior, but you need the version number to handle new options. Once you have that you can change the default behavior based on the version level so that older users operating in older repositories get the old behavior, and new repositories get the new behavior. And you have more flexibility in how your approach these problems when they come up, and it seems to me that they are inevitable. 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