Re: [RFC PATCH] push: start warning upcoming default change for push.default
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Mar 14, 2012, 09:07 UTC
- Message-ID
- <vpqhaxrzh2a.fsf@bauges.imag.fr>
- In-Reply-To
- <CAHkcotg1FKxfMR4Fe9Xfo_i4nuxzXdfVWe80HZu0wQEkiXhhmA@mail.gmail.com>
Dmitry Potapov <dpotapov@gmail.com> writes:
Show 19 quoted lines
> 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?
Show 6 quoted lines
>> 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.
Show 7 quoted lines
>> 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/