Re: [RFC PATCH] push: start warning upcoming default change for push.default

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Mar 9, 2012, 18:30 UTC
Message-ID: <4F5A4C45.7070406@xiplink.com>
In-Reply-To: <1331288715.21444.38.camel@beez.lab.cmartin.tk>

On 12-03-09 05:25 AM, Carlos Martín Nieto wrote:

Show 45 quoted lines

> On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote:
>> More inexperienced users will often push right after committing, and at
>> that time they're still very much in the "working-on-one-branch" state of
>> mind.  "upstream" would be a safer default mode of operation for 'git push'
>> for them even when they have their personal publishing repository (also in
>> a shared public repository settings, "matching" is rarely the right
>> default mode).
>>
>> In preparation for flipping the default to the "upstream" mode from the
>> "matching" mode that is the upstream default, start warning users when they
>> rely on unconfigured "git push" to default to the "matching" mode.
>>
>> Original patch and commit message by: Junio C Hamano<gitster@pobox.com>
>>
>> Signed-off-by: Matthieu Moy<Matthieu.Moy@imag.fr>
>> ---
>>
>> This patch prepares a transition to 'upstream', unlike the previous
>> version which was advertizing 'current'. In most case, this would be
>> the same, but 'upstream' is probably more sensible in case it points
>> to a branch other than 'current'. I don't care much either way.
>>
>
> For people using git as VCS that happens to have local history rather
> than taking full advantage of the distributed nature (or who aren't
> aware of it or don't get it), 'matching' is bound to be confusing.
> However, IMO 'current' makes more sense. Consider
>
>      git clone ../foo; cd foo;
>      git checkout -b topic origin/develop
>      ed main.c
>      git push
>
> With upstream I've just updated origin's dev branch, even though I might
> have meant to create a new 'topic' branch. Alternatively, I might have
> run
>
>      git checkout -b topic
>
> in which case I certainly want 'current'. I don't see that workflow
> where the upstream branch is named differently from the local one should
> be that big a consideration when trying to determine a default to help
> people unfamiliar as they'd be certainly more likely to consider branch
> names to be binding. Maybe you have seen this differently in your
> students, but that's the impression I get from #git.

I disagree and consider "upstream" to be the more reasonable default.

I think that an incantation like

	git checkout -b topic origin/master

makes it pretty clear that topic is meant to be merged into origin's master branch. And so a simple "git push" as you describe I think *should* update origin's master branch.

OTOH, with a default of "current" I believe the simple "git push" will create a new branch named topic in the origin repo. To me that's implying too much from the simple "git push" command. If the user really wants a branch named topic in the origin repo, I think it's reasonable for git's default behaviour to require the user to say so explicitly ("git push origin topic").

I also disagree that an incantation like

	git checkout -b topic

means that the user wants "current" when they "git push". There's no indication here that the user is at all interested in remote branches with this topic, and I think it would be presumptuous for git to make such a link by default. (Besides, what if the user has more than one remote? Which should be used?)

In this case the "upstream" default would mean that git couldn't 
identify a remote for the topic branch and so the "git push" would fail. 
  I think that's appropriate, because the user never told git how the 
topic branch relates to any remote branches.

M.