topic.linear-merge = allow-from-bare-branch and hg-git
Uwe Brauer
oub at mat.ucm.es
Thu Dec 10 13:25:55 UTC 2020
>>> "DVPC" == Dan Villiom Podlaski Christiansen <danchr at gmail.com> writes:
> On 3 Dec 2020, at 21.58, Uwe Brauer <oub at 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://oub@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://oub@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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5673 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20201210/44c087eb/attachment.p7s>
More information about the Evolve-testers
mailing list