Re: About overzealous compatibility

[Felipe Contreras <felipe.contreras@gmail.com>]

On Sun, May 19, 2013 at 2:56 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> > On Fri, May 17, 2013 at 1:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> >> So when "the user" is running "git fetch" on "mywork" branch that
>> >> happens to be forked from a local "master",...
>> >> we still need to have FETCH_HEAD updated to point at what we would
>> >> be merging if she did a "git pull".
>> >
>> > No, we don't need that. That is only needed by 'git pull', and in
>> > fact, it should be possible to reimplement 'git pull' so that it skips
>> > FETCH_HEAD when the remote is local.
>> >
>> > These are mere implementation details.
>>
>> You seem to be incapable to understand what backward compatibility
>> is.
>
> Really? Do you even remember the time when you changed out of nowhere
> all the 'git-foo' commands with 'git foo' and all hell broke loose?
>
> I remember some lonely voice of reason shouting for clear deprecation
> warnings:
>
> http://article.gmane.org/gmane.comp.version-control.git/94262

After re-reading this old thread, I noticed that you didn't get a
straight answer, nor was there a neat conclusion, and the good replies
might have been lost in the noise. So this is what you should have
done:

1) Fix all the tests and documentation to use the 'git foo' form, so
everything is consistent and the proper form of the commands is
explained.
2) Release v1.6.0 turning on annoying deprecation warnings telling
people to stop using 'git-foo'. This wouldn't have had the same bad
effect that v1.6.0 had, because you added at the same time a
configuration to turn the annoying message off, so users, and
administrators can choose to ignore the warning, and then they
couldn't complain when the 'git-foo' links get removed for real.
3) To be absolutely sure that people get the message that there's a
big change, name the release v2.0.

I think 3) would have been overkill; v1.7.0 would be OK, but 2) was
definitely needed, and 1) would have been great.

I think it's extremely cheap that you accuse me of not understanding
backwards compatibility, when I did for zsh's completion[1] exactly
what you should have done for v1.6.0: add an annoying deprecation
warning.

Cheers.

[1] http://article.gmane.org/gmane.comp.version-control.git/210024

-- 
Felipe Contreras