push should not allow to push diverged bookmark

[Ryan McElroy]

On 9/3/2015 6:20 AM, Marc Strapetz wrote:
> On 07.08.2015 09:00, Marc Strapetz wrote:
>> On 07.08.2015 00:24, Pierre-Yves David wrote:
>>>
>>>
>>> On 08/04/2015 05:26 AM, Marc Strapetz wrote:
>>>> When having a bookmark for which there exists a new remote commit, 
>>>> it's
>>>> still possible to push a diverged local commit without --force 
>>>> option. I
>>>> think it's more reasonable to disallow such pushes, similar as when
>>>> pushing a branch or a specific revision. The patch below should 
>>>> resolve
>>>> the problem.
>>>
>>> Can you give more details about the problematic cases ?
>>
>> Basically, every push of a bookmark is problematic. Consider following
>> scenario:
>>
>> Remote Repo ("default"):
>>
>> r2 (ed20) o <bm>
>>            |
>> r1        o
>>            |
>> r0        o
>>
>> Local Repo:
>>
>> r2 (3b28) o <bm>
>>            |
>> r1        o
>>            |
>> r0        o
>>
>> Now pushing the bookmark succeeds and creates a new head. This is
>> usually not expected, but the push should fail instead.
>>
>> $ push -B bm default
>> pushing to .../remote
>> searching for changes
>> remote has heads on branch 'default' that are not known locally:
>> ed2016a85e51
>> adding changesets
>> adding manifests
>> adding file changes
>> added 1 changesets with 1 changes to 1 files (+1 heads)
>> updating bookmark bm
>
> Any other opinions on that?
>
> -Marc

I strongly agree with the direction of this patch. I wasn't even aware 
it was possible to push a new head on a single branch without --force, 
but I tested it out and sure enough, this happens!

That feels like a regression to me (normally new heads on a branch are 
not allowed without --force, right?) But when you send a new head with a 
bookmark, it's accepted? This feel broken to me at several levels; this 
patch is a good fix for one of those levels.

I agree with @pyd that we should have a test to ensure we don't regress 
this behavior.