On Fri, May 2, 2014 at 2:13 PM, Junio C Hamano <gits...@pobox.com> wrote:
> 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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html