Re: Pull is Mostly Evil

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 2, 2014, 20:58 UTC
Message-ID: <53640701f135a_135215292ec1@nysa.notmuch>
In-Reply-To: <xmqqtx989c9d.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:

Show 13 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> >> Stepping back even further, and thinking what is different between
> >> these two pulls, we notice that the first one is pulling from the
> >> place we push back to.  Perhaps a way to solve this issue, without
> >> having to introduce a new 'git update' and updating the tutorials,
> >> may be disallow fetch+merge by default only when pulling from the
> >> place the result is going to be pushed back to?
> >
> > Which is basically essentially the same as not specifying anything, or
> > rather, running `git pull` without arguments.
> 
> I cannot tell if you are agreeing or disagreeing, and with what.

I'm agreeing that 'git pull repo branch' is different than 'git pull', and 'git pull' is the problem. I'm not certain about 'git pull repo', but I think that probably shouldn't change either.

> Using the "special case 'git pull' without arguments" heuristics
> would take us back to the old jc/pull-training-wheel patch
> 
>     http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=230856

If you mean adding back the 'test $# = 0', then yes, if you mean going back to 'pull.rebase=false' to force merges (and a bunch of other stuff), then no.

Show 6 quoted lines

> which we agreed to drop in
> 
>     http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365
> 
> to favor the old series you did with pull.mode, and we rejected that
> patch in $gmane/230856 for a sound reason, I would think.

Because the 'pull.mode=merge' mode option was simply sensible.

Show 15 quoted lines

> "You are pulling from the place the result is going to be pushed
> back to" is different from "'git pull' was run without arguments".
> In the "pumpking" example in the message you are responding to:
> 
>     When he becomes in charge of producing a new 'maint' (in his
>     original, he says 'maintenance-branch'), he first does this:
> 
>         $ git checkout maint
>         $ git pull --ff-only [ origin maint ]
> 
> the heuristics would trigger the safety only when the optional
> "origin maint" are not given, but we do have enough information
> to see "git pull origin maint" (with where from and what to pull
> explicitly specified on the command line) falls into the case where
> the user needs protection, don't we?

I think 'git pull' and 'git pull origin maint' are different, regardless of the fact that origin/maint is the upstream.

In the former I would expect 'maint' to be merged to 'origin/maint', in
the latter I would expect 'origin/maint' to be merged into 'maint'. And
if the user has specified that he wants to merge 'origin/maint' into
'maint', I don't see why a non-fast-forward should fail.

> Also, with the triangular push configuration, "git pull" without
> argument will fetch from one place that is different from where the
> current branch is going to pushed to, so that heuristics would not
> work at all.

I think that's irrelevant. Both the upstream and publish tracking branches don't matter when the user has specifically asked for a branch to be pulled.

-- 
Felipe Contreras