topic.linear-merge = allow-from-bare-branch and hg-git

[Uwe Brauer]

Hi

The following unfortunately does not work. I clone a git repository and
want to do a no-fast-forward merge using the new topic.linear-merge = allow-from-bare-branch
from evolve.

The merging works but then I cannot push:

Here are the steps to reproduce whats happening.
hg clone git+ssh://o...@git.code.sf.net/p/matlab-emacs/src
mv src/
mv src/ matlab-sf-hg
cd matlab-sf-hg
hg topic -r 'f452f1652810:tip' usage2
hg up master
hg merge tip
hg ci "Merge usage1 into master"

Hg push
pushing to git+ssh://o...@git.code.sf.net/p/matlab-emacs/src
Warning: Permanently added 'git.code.sf.net,216.105.38.16' (ECDSA) to the list of known hosts.
searching for changes
abort: pushing refs/heads/usage1 overwrites fdc13a48aa41

[Dan Villiom Podlaski Christiansen]

Generally speaking, hg-git is aware of neither topics nor history evolution — and the same applies to Git. A bare `hg push` will push all changes from the repository — similar to regular Mercurial.

In your workflow above, this command:

> hg topic -r 'f452f1652810:tip' usage2

…implicitly removes `f452f1652810:tip` from whatever (Git) branch it was on, and assigns it to `usage2`. The error from push indicates that it was on usage1. In other words, you’re rolling back usage1 when pushing. Consistent with Git, that should trigger an error; to bypass this, either do an explicit `hg push -r usage2` or do a bare `hg push --force` — although latter is almost never a good idea, as it really does overwrite _everything_.

So the end result is that the error is “correct”, strictly speaking, if somewhat unhelpful. I hope to address this eventually, but it requires changes to how push and pull work, so it’s rather invasive.

I hope my response was helpful?

- Dan

[Uwe Brauer]

>>> "DVPC" == Dan Villiom Podlaski Christiansen <dan...@gmail.com> writes:

> On 3 Dec 2020, at 21.58, Uwe Brauer <o...@mat.ucm.es> wrote:
>> Hi
>>
>> The following unfortunately does not work. I clone a git repository and
>> want to do a no-fast-forward merge using the new topic.linear-merge = allow-from-bare-branch
>> from evolve.
>>
>> The merging works but then I cannot push:
>>
>> Here are the steps to reproduce whats happening.
>> hg clone git+ssh://o...@git.code.sf.net/p/matlab-emacs/src
>> mv src/
>> mv src/ matlab-sf-hg
>> cd matlab-sf-hg
>> hg topic -r 'f452f1652810:tip' usage2
>> hg up master
>> hg merge tip
>> hg ci "Merge usage1 into master"
>>
>> Hg push
>> pushing to git+ssh://o...@git.code.sf.net/p/matlab-emacs/src
>> Warning: Permanently added 'git.code.sf.net,216.105.38.16' (ECDSA) to the list of known hosts.
>> searching for changes
>> abort: pushing refs/heads/usage1 overwrites fdc13a48aa41

> Generally speaking, hg-git is aware of neither topics nor history
> evolution — and the same applies to Git. A bare `hg push` will push
> all changes from the repository — similar to regular Mercurial.

Let me start with a confession. I am no fan of fast forward merge, and I
am grateful that git provides no-fast forward merges.


Since I manage the git repositories I have access to, via hg-git, I first looked for a
no-fast-forward merge in mercurial (without using named branches), so
topics in evolve were a candidate. [1]

I was not sure to which extend hg-git does support evolve and so I gave
it a try.

BTW, I use Manuel Jacob's patches supporting named branches (or topics
but not really both) in hg-git. I am not sure whether they are now in
the default or stable branch.
Changeset bc1841341adb
and
e8045105764b

> In your workflow above, this command:

>> hg topic -r 'f452f1652810:tip' usage2

> …implicitly removes `f452f1652810:tip` from whatever (Git) branch it
> was on, and assigns it to `usage2`. The error from push indicates that
> it was on usage1. In other words, you’re rolling back usage1 when
> pushing. Consistent with Git, that should trigger an error; to bypass
> this, either do an explicit `hg push -r usage2`

The problem with this is that I would most likely end with a new branch
in git called usage2, but I will try to check this on a sanbox setting.

> or do a bare `hg push
> --force` — although latter is almost never a good idea, as it really
> does overwrite _everything_.

Oops I am really afraid of the force option

> So the end result is that the error is “correct”, strictly speaking,
> if somewhat unhelpful. I hope to address this eventually, but it
> requires changes to how push and pull work, so it’s rather invasive.

It think it would be great we you did that.

> I hope my response was helpful?

Definitely

Uwe

Footnotes:
[1] Independent of hg-git I think it is a useful feature.