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

From: Jeff King <peff@peff.net>
Date: Nov 5, 2008, 03:05 UTC
Message-ID: <20081105030525.GC20907@coredump.intra.peff.net>
In-Reply-To: <7vr65rqnoj.fsf@gitster.siamese.dyndns.org>

On Tue, Nov 04, 2008 at 11:46:36AM -0800, Junio C Hamano wrote:

Show 9 quoted lines

> 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.

Hmm. It really seems to me that there are two desires for push behavior, based on particular workflows. I.e., some people seem to want the matching behavior by default, and others want to push the current branch.

And we already can control that via configuration of the refspec. So any argument that "git push should do the same thing even on somebody else's setup" is already wrong. But I do think Junio has a good point, which is that there is going to be confusion if upgrading git suddenly causes "git push" to do something else.

So why not take one step back in the behavior change? We can set up the "push just this branch" refspec during clone, which will leave existing repositories untouched. And to make things even gentler, we can start with opt-in to the clone feature, notify users via the release notes (which, as we have established, EVERYONE reads), and then decide if and when to switch the option on by default.

So something like a "remote.push" config option, the value of which gets added to newly created remotes (including those created on clone). It would default to ":", but you could easily set "git config remote.push HEAD" to get the other behavior.

No, this doesn't get rid of the eventual need to choose whether to switch the default. But I think it eases us into it a little more. And I think such an option is a lot more generally applicable than a "default push to matching versus HEAD" option.

-Peff