Re: Please discuss: what "git push" should do when you do not say what to push?

[Andrew Sayers <andrew-git@pileofstuff.org>]

On 19/03/12 21:43, Junio C Hamano wrote:
> Andrew Sayers <andrew-git@pileofstuff.org> 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