On Fri, May 2, 2014 at 2:13 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: [snip] > Your earlier long-hand, together with the two examples that pulls > into the same "maint" branch Brian gave us, may give us a better > starting points to think about a saner way. > > To me, the problem sounds like: > > Tutorials of Git often says "use 'git pull' to catch up your > branch with your upstream work and then 'git push' back" (and > worse yet, 'git push' that does not fast-forward suggests doing > so), but 'git pull' that creates a merge in a wrong direction is > not the right thing for many people. Yes, that's a good portion of the problem. > And proposed solutions range from "let's write 'pull' off as a > failed experiment" to "let's forbid any merge made by use of 'pull' > by default, because it is likely that merge may be in reverse". FWIW, at my company, we took another approach. We introduced a `git ffwd` command that fetches from all remotes, and fast-forwards all your local branches that are tracking a remote, and everyone on the team uses it all the time. It should be said this team also likes to use Git bare-metal, because they like knowing how things work out-of-the-box. But they all use the command because it's so convenient. I had started making a C version a while back, but never completed it. I could take a stab at doing so again, if there's interest. -John -- 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