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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John Keeping <john@xxxxxxxxxxxxx> 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.

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.

>  Similarly, if "--ff",
> "--no-ff" or "--ff-only" are given then we can infer "--merge" in the
> absence of any other configuration.

Isn't that already there in the patch to git-merge?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]