Search code examples
mercurialbranchsynchronizationtortoisehgsynchronize

Mercurial TortoiseHG - How to align updates between branches?


Considering a project in TortoiseHG with 3 branches ("default", "Phase 1", "Phase 2"), is it possible to make changes to one branch and make them reflect in one or both of other ones, without merging them?

The idea is to correct a bug in one branch and not have to "update" to each of the other branches to correct the same bug there.

If so, how is it done? Is it synchronization? Push? Something else?

Could someone tell me what the steps are to make this happen (assuming it is doable)?

Thanks Setnara


Solution

  • Yes, it's possible and I see at least 2 obvious and one nice solutions, but

    NEVER USE OBVIOUS IN FUTURE AND FIX BRAINLESS WORKFLOW ASAP! IT'S NIGHTMARE TO HANDLE SUCH PROJECTS FROM CODE-MONKEYS LATER!!!


    Rebase-style

    • Rebase changesets (hg help rebase), starting from first changeset of bugfix, into new targets (Heads of branches) hg rebase -s $BUGFIX_START -d Phase 1 + hg rebase -s $BUGFIX_START -d Phase 2 (in assumption that bugfix is part of default branch), keeping rebased changesets in original branch hg rebase ... --keep
    • Resolve possible conflicts
    • Because rebase will rebase all descendants of $BUGFIX_START, with probably some changesets unrelated to bugfix, hg strip not-bugfix changesets from rebase-destinations

    Graft-style

    • Graft (hg help graft) allow inject individual changesets from one part of tree into another (contrary to rebase, which inject subtree from custom node or merge, which inject all history from greatest common ancestor). You have to:
      • update to destination branch (hg up Phase 1), read hg help update
      • select all needed changesets and enumerate in rebase (see -r options of command) hg graft -r $BUGFIX_START -r $BUGFIX2 ... -r $BUGFIXN -D -U --log
      • perform two previous steps with Phase 2 branch

    and, at last

    "The Right Way" (tm) - Named Branching

    • Create named branch from the point or parent for $BUGFIX_START hg up $BUGFIX_START + change something + hg branch SEMANTICNAMEOFBUGFIX``hg ci -m "Branch for $BUGFIX"
    • Rebase (with stripping after, if needed, and without --keep) bugfix-related changesets into this new named branch
    • Merge SEMANTICNAMEOFBUGFIX into default, Phase 1, Phase 2
    • Always use "Branch Per Task" in future, stop spaghetti-bullshit in code and repository-histories

    I translate a beam of contempt to your mentor: He had to tell and explain it before authorizing public commits (local personal repository can be a nightmare to any extent)

    I highly recommend reading not only the code, but the documentation and advices and hints from wise and experienced users, in order do not constantly reinvent the wheel