StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Tonfa is right. What you're describing isn't 'merging' (or 'pushing' or 'pulling'); it's 'cherry-picking'. A push or a pull moves all the changesets from one repo to another that aren't already in that repo. A 'merge' takes two 'heads' and merges them down to a new changeset that's the combination of both.</p> <p>If you really need to move G over but can't possibly abide having D,E,F there you should 'hg export' G from repo A, and then 'hg import' it in repo A. The <a href="https://www.mercurial-scm.org/wiki/TransplantExtension" rel="nofollow noreferrer">Transplant extension</a> is a wrapper around export/import with some niceties to help avoid moving the same changeset over multiple times.</p> <p><strong>However</strong>, the drawback to using import/export, transplant, and cherry-picking in general is that you can't really move over G without its ancestors, because in Mercurial a changeset's <em>name</em> is its 'hashid' which includes the hashids of its parents. Different parents (G's new parent would be C and not F) means a different hashid, so it's not G anymore -- it's the work of G but a new changeset by name.</p> <p>Moving over G as something new, let's call it G' (Gee prime), isn't a big deal for some uses, but for others it's a big pita. When soon repo B get's a new changeset, H, and you want to move it over its parent will be changing from G to G', which have different hashes. That means H will move over as H' -- 100 changesets down the line and you'll have different hashids for everything all because you couldn't stand having D,E,F in repo A.</p> <p>Things will get even more out of whack if/when you want to move stuff from Repo A into Repo B (the opposite direction of your earlier move). If you try to do a simple 'hg push' from A to B you'll get G' (and H' and by subsequent descendants) which will be duplicates of the changesets you already have in Repo B.</p> <p>What then, are your options?</p> <ol> <li><strong>Don't care.</strong> Your data is still there you just end up with the same changesets with different names and more work on future exchanges between the two repos. It's not wrong, it's just a little clumsy maybe, and some folks don't care.</li> <li><strong>Move all of D,E, and F over to Repo A.</strong> You can move all the changesets over if they're harmless and avoid all the hassle. If they're not so harmless you can move them over and then do a 'hg backout' to undo the effects of D,E and F in a new changeset H.</li> <li><strong>Give G better parentage to begin with.</strong> It's mean for me to mention this because it's too late to go this route (without <a href="https://www.mercurial-scm.org/wiki/EditingHistory" rel="nofollow noreferrer">editing history</a>). What you <em>should</em> have done before working on changeset G was to <code>hg update C</code>. If G doesn't rely on or require changesets D,E, and F then it shouldn't be their kid.</li> </ol> <p>If instead you update to C first you'll have a graph like this:</p> <pre><code>A - B - C - D - E - F \ G </code></pre> <p>then, the whole answer to this question would just be <code>hg push -r G ../repoA</code> and G would move over cleanly, keeping its same hashid, and D, E, and F wouldn't go with it.</p> <p><strong>UPDATE:</strong></p> <p>As pointed out in the comments. With modern Mercurials the <code>hg graft</code> command is the perfect way to do this.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload