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

On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy
[off-list ref] wrote:

Jeff King [off-list ref] writes:

quoted

  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. If there is
a centralized workflow with only one branch then everything is simple,
but it is not so with other workflows.

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.

Now, if pushing sends commits to a branch other than 'upstream', you can
get the following scenario:

$ git push
To bla
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'bla'

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.

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

Back to my students, most of them will never get in this situation
because they won't use branch, so HEAD = master and upstream =
origin/master,

So, there is no real difference between 'current' and 'upstream' for
them.

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.

quoted

So far a lot of the discussion has focused on "what is the most sensible
default for the most number of people". But I wonder if a better
question is "what is the default that is the least likely to do
something dangerous and embarrassing".

I think "what's the most intuitive" is also very important.

But it depends on the workflow that is employed by the project.
Different projects may have different workflows. We can assume that
the person who sets up the repository has good knowledge of Git and
how to use it, but many others who work on the same project may not
know Git well. For them "the most intuitive" means whatever policy
this project has.


Dmitry