Re: [PATCH] Documentation: add a planning document for the next CLI revamp

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2008, 19:46 UTC
Message-ID: <7vr65rqnoj.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1225822231.6722.3.camel@maia.lan>

Sam Vilain <sam@vilain.net> writes:

Show 10 quoted lines

> On Tue, 2008-11-04 at 12:18 +0300, Dmitry Potapov wrote:
> ...
>>  The only one who does publishing to the official repository
>> is the maintainer, and the maintainer is most likely to run some tests
>> after merging all changes, which takes some time. So, it is rarely push
>> the current branch, it is usually the branch that has been tested, so
>> the name of the branch should be specified explicitly anyway.
>
> Why is that relevant?  That person can still use the explicit version of
> the command.

Back when "git push $there :" were not available, the default matching behaviour was the _only_ way to say "I know the set of branches I want to publish, and I have many more private branches in my primary work repository. I do not want to list the set of branches to publish every time when I type 'git push', nor I want to configure it --- Heck, I shouldn't have to list them, the public repository I am pushing to already has that list, and it is the set of branches that exist there".

These days, people who would want the maching behaviour can explicitly ask for it, so there is one less reason to resist changing the default (i.e. earlier explicitly askinf for "matching" was impossible, but now we can). The remaining reason of resistance is pure inertia (i.e. not changing the behaviour of the command only because you upgraded your git), and the only way to address it is to start issuing the warning when "git push" or "git push $there" is used and the matching behaviour was chosen without configuration (i.e. no "remote.<there>.push = :"), and keep it that way for two release cycles, and finally change the default.