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

Reply via email to