Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull

[John Keeping <john@keeping.me.uk>]

On Fri, Jun 28, 2013 at 10:22:57AM -0700, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
> 
> >>  test_expect_success \
> >>      'merge-setup part 3' \
> >> -    'git pull . branch1'
> >> +    'git pull --merge . branch1'
> >
> > I think the "--merge" should be implied here because the suer has
> > specified an explicit remote and branch.
> 
> The whole point of the topic is "It used to be that when you said
> 'git pull' and did not tell us your preferred way to integrate your
> work and work by the others', we default to merging, but we no
> longer do so---you have to choose."
> 
> Here, "git pull . branch1" is merely saying "I want to integrate
> the work on my current branch with that of branch1" without saying
> how that integration wants to happen.

The change that I think is important is that the "bring my branch
up-to-date" operation should force the user to choose what to do if the
branch does not fast-forward to its upstream.  If that was spelled "git
update" then having "git pull" perform a merge would be fine, but we
spell this operation as "git pull" so the change needs to happen there.

I don't think "git pull remote branch" falls into the same category as
plain "git pull" so I'm not convinced that defaulting to merge there is
unreasonable.  The original message about this [1] did talk about only
"git pull" with no arguments.

> Even though, as an old timer, I find it mildly irritating that we
> now have to be explicit in these tests, this change is in line with
> the spirit of the topic.  If we didn't have to change this example
> and the pull silently succeeded without complaining, we achieved
> nothing.

I disagree that we would have achieved nothing.  New users will not be
using explicit arguments to git-pull when just trying to bring a branch
up-to-date.

[1] http://article.gmane.org/gmane.comp.version-control.git/225240