0

Forgive me, this may well have been asked before, but I can't find my way through all the complicated options to the simple thing I want to do.

On my default branch I do primary development. A while back I created a "beta" branch (now at version 160) to allow a beta tester to work on a stable version, while primary development continued. (now at version 200)

Now it's time to update the beta branch to equal the content of the default branch as it now is. No merge, no fancy discussion, just full-on replace whatever is in the beta branch with whatever is now at the tip of the default branch. Is this a job for graft?

I see a lot of discussion about moving "commits" from one branch to another, but does that mean the same thing as moving the entire content if I use the latest commit?

A command line example would be most helpful.

Joymaker
  • 813
  • 1
  • 9
  • 23
  • 1
    Possible duplicate of [Mercurial: make one branch identical to another](https://stackoverflow.com/questions/13092020/mercurial-make-one-branch-identical-to-another) – torek Jun 04 '19 at 00:28
  • Using a certain kind of merge is exactly what you want here, despite stating otherwise. The merge "other" in Torek's answer is super easy to use. – StayOnTarget Jun 04 '19 at 11:24

1 Answers1

1

I posted a close-request-link to a likely duplicate (Mercurial: make one branch identical to another) but I thought I would add the following...

Grafting is definitely not what you want here. Grafting means copying a changeset, or some number of changesets, from one branch or thread-within-a-branch1 to another.

It is possible to use hg merge to copy a different branch's tip commit (or any non-tip commit, really) to your own branch using the :other built in merge-tool.2 This records an actual merge, unlike the other answer's close-and-reopen method. There's no particular reason to favor one method over the other.

1It's not clear what to call these. Edit: Mercurial documentation calls these anonymous branches. You get them when you use Mercurial in a more Git-like fashion, using bookmarks to keep track of multiple heads within a single named branch:

                  c4--c5   <-- bookmark1
                 /
default:   c1--c2--c3   <-- bookmark2
                     \
                      c6--c7--c8   <-- bookmark3

In Git, these bookmarks are the branches: there are no permanent branches at all, and all you get are bookmarks.

(Side note: it's not clear if Mercurial considers c3 an anonymous branch. Commit c3 is not a head, and will not be listed by hg heads, even though it has a bookmark identifying it. The anonymous branch effectively sprouts later, if and when you update to the bookmark and then create a new commit, dragging the bookmark along to track its progress.)

2This is the equivalent of Git's missing -s theirs merge strategy. Compare with :local, which is the equivalent of Git's -s ours strategy, and contrast tis with :merge-local or :merge-other, which merge changes from both sides, but favor our or their side for automatic merge conflict resolution.

torek
  • 448,244
  • 59
  • 642
  • 775
  • I usually refer to the "threads" (1) as "unnamed branches" because other than lacking a name they behave like named branches in most or all other aspects. I think you could also refer to them as heads although that doesn't seem to convey quite the same meaning. – StayOnTarget Jun 04 '19 at 11:25
  • Yeah, I think "heads" in Mercurial implies just the tip commits, e.g., includes `c5` but not `c4`. Also, in the setup I drew, `c5` and `c8` are heads but `c3` is not, even though it has a bookmark identifying it. – torek Jun 04 '19 at 16:27
  • I never noticed this before, but hg itself calls these "anonymous branches". From here: $ hg help glossary .. " Branch, anonymous Every time a new child changeset is created from a parent that is not a head and the name of the branch is not changed, a new anonymous branch is created." – StayOnTarget Jun 04 '19 at 17:36