Re: git push default behaviour?

[demerphq <demerphq@gmail.com>]

On 9 March 2012 06:38, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> 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/"