On Tue, Mar 13, 2012 at 1:34 PM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> 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. 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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html