Re: Pull is Mostly Evil

From: John Szakmeister <john@szakmeister.net>
Date: May 3, 2014, 10:00 UTC
Message-ID: <CAEBDL5USVuFDXQk7Cb9cJ8Lm4RJNeJB0DwZBCB1cXmkroD8w3g@mail.gmail.com>
In-Reply-To: <xmqqoazgaw0y.fsf@gitster.dls.corp.google.com>

On Fri, May 2, 2014 at 2:13 PM, Junio C Hamano <gitster@pobox.com> wrote: [snip]

Show 11 quoted lines

> 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