On Fri, Jun 28, 2013 at 10:22:57AM -0700, Junio C Hamano wrote:
> John Keeping <j...@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  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
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
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