>>> "DVPC" == Dan Villiom Podlaski Christiansen <[email protected]> writes:
> On 3 Dec 2020, at 21.58, Uwe Brauer <[email protected]> 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://[email protected]/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://[email protected]/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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Evolve-testers mailing list [email protected] https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
