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

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Dmitry Potapov <dpotapov@gmail.com> writes:

> On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>>   1. If you are a new user who does like the implicit merge, you may
>>>      find it convenient not to have to learn about "git checkout; git
>>>      merge topic ; git push remote master". But it only helps you
>>>      _sometimes_. If master has had other work built on it, your push
>>>      will fail, and you will have to do the merge yourself. So it is
>>>      only helping you by omitting a step some of the time, and you still
>>>      have to learn why the step is sometimes necessary and sometimes
>>>      not.
>>
>> There's a rule of thumb which works very well for beginners: when "git
>> push" tells you to pull before, then pull before. This rule of thumb
>> works, but only provided "push" and "pull" are symmetrical.
>
> I am not sure what you mean by symmetrical here, because they are never
> truly symmetrical as "pull" does merge and "push" does not.

I mean "they work with the same branch".

> If there is a centralized workflow with only one branch then
> everything is simple, but it is not so with other workflows.

I don't get this. With either 'current' or 'upstream', both pull and
push deal with one local and one remote branch. The only asymetry is the
case of non-fast forward (push fails, pull merges). But it's all about
transmitting changes from a branch to another, in one or another
direction.

> Moreover, doing 'git pull' too often (unless it is 'git pull --rebase)
> pollutes history with useless merges, making more difficult to review
> changes, or doing git-bisect.

What's your point here? How does it invalidate the rule of thumb above?

Whether you want to pull often or not, it does not change the fact that
you cannot do non-fast forward push (at least, not without losing
history). If the user tried to push, what would you suggest if not
pulling (or merging in whatever way you want)? Blame the user who wanted
to push that he shouldn't have tried that?

> I agree that the current diagnostic is not suitable for beginners.
> Not-fast-forward push is something that beginners should never use,
> but from this message is not clear what is the alternative to forcing
> non-fast-forward push.

Again, what would you suggest? Teach --force to beginners?

>> One can easily get in this situation even in a kernel-style workflow:
>> work from your desktop, push, work from your laptop, try to push and it
>> fails.
>
> IMHO, when you often switch between your desktop and laptop, 'matching'
> makes much more sense.

Then, if you worked on branch 'foo' from your desktop, and 'bar' on your
laptop, you'll get errors about non-fast forward push from both machines.

> If 'push' fails then usually I want to force non- fast-forward push,
> because the new series contain reworked patches that already were on
> the other computer.

... but if they were not, you've just silently errased your previous
work. I have no problem with you working like this, but please don't
teach that to beginners.

>> but the not-so-newbies may get this once they start
>> creating branches ifever they have HEAD = topic-branch and upstream =
>> origin/master for example.
>
> The real question is what one expects from 'push' in that situation. It
> could be pushing this branch back to the upstream branch or creating a
> new feature branch in the upstream.

Yes. But both of them are covered by 'push.default=upstream', depending
on how you configured the upstream.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/