2

We have three related Mercurial repos that we are currently using in our development. Shown here, we have:

  • A released version One (Base is released, and we have an upcoming patch),
  • An in-house version Two that differs from One only in some of the test code used by our CI system,
  • An up coming release Three.

enter image description here

After being committed to a repo, changes are always pushed to the "lower" repos. My problem is that the changeset A2 (and in hindsight, possibly A1) was merged directly into Three before being merged into Two.

Currently, the tip of repo Two will not merge (heavy dashed line) onto Three without numerous conflicts, even though all the constituent changes are in Three.

The options I see are:

  1. Re-merging A2 and B2 and use hg commit --close-branch to eliminate the confusing merge, then push the replacement merge onto Three.
  2. Re-merging A2 and B2 and hg strip off the confusing merge. Sadly I cannot strip the hosted repo, so I'd have to do a little dance to replace the repo there (and inform the small team that uses that repo).
  3. Merge the current tip of Two onto Three and go through the tedium of a few dozen "conflicts".

My question is what's the best way to resolve this simply? Also, how could this happen in the first place?

Question 17169232

Note that the image is simplified, there are typically several changesets that are pushed to a repo before being merged to the next.

Community
  • 1
  • 1
Friendly Fire
  • 55
  • 7
  • You are doing a [criss-cross merge](http://www.gelato.unsw.edu.au/archives/git/0504/2279.html) (where the two parents of your merge do not have a *single* common ancestor), and Mercurial doesn't really like those. You might try the [bid merge](https://www.mercurial-scm.org/wiki/BidMerge) algorithm, but be sure to test/audit the result thoroughly since this is an experimental feature. – Kevin Oct 20 '15 at 16:32

0 Answers0