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

[Marc Branchaud <marcnarc@xiplink.com>]

On 12-03-09 05:25 AM, Carlos Martín Nieto wrote:
> 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.