1

I'm a solo hobbyist developer with some code hosted on Bitbucket. I use TortoiseHg client-side for managing my repo.

Back in 2013 I developed a feature on a branch but abandoned it before completion.

The default branch has seen many commits and structural improvements since that time.

Now I'm to a point where that abandoned branch's feature has become appealing again, and I'd like to resume working on it.

First, however, I'd like to bring it up to compliance with the existing site design.

I'm unclear on what the correct Mercurial step is for reviving this branch? It seems obvious that I don't want to Merge with Local... with local being the most recent default code. Update to... would pull the most recent commit from the old branch down to my computer, which wouldn't have any of the system-wide improvements made over the intervening years. So?

2
  • 1
    I'm unfamiliar with Mercurial, so I'll leave this as a comment: in git, I would create a branch off your abandoned branch, merge the new code into it, and once I was happy with its state, merge it back into the abandoned branch and continue development. For simpler merges I might forgo branching off and work directly on the original abandoned branch. Someone who knows how Mercurial works might be able to adapt this :)
    – Iker
    Commented Oct 21, 2016 at 9:36
  • Here is a similar question (not Mercurial specific so I'm not marking this as a duplicate) softwareengineering.stackexchange.com/questions/302289/…
    – user82096
    Commented Oct 21, 2016 at 13:10

1 Answer 1

Reset to default
1

You want (in common) merge default to feature (resolving a lot of possible merge-conflicts).

Slightly different way:

  • convert all changesets of feature branch into the set of MQ-patches
  • create new named branch from current tip
  • Apply patches from queue consecutively from bottom to top, resolving conflicts for every single changeset's changes

PS: As @IMSoP noted, instead of MQ-game it can be just rebase (feature branch to the fresh branchpoint), it's just a question of tastes: resolve (possible) conflicts for final states of conflict-ranges in case of rebase (imagine more than single change in range in conflict in revset) or resolve it in sequence individually for each changeset, which produced merge-conflict

4
  • The "generate a set of patches and reapply one by one" sounds a lot like git's "rebase" function.
    – IMSoP
    Commented Oct 21, 2016 at 11:41
  • Yep, that's pretty much rebase.
    – DeadMG
    Commented Oct 21, 2016 at 11:42
  • @IMSoP - yes, it's rebase (VCS-agnostic) in common, but with small difference - you'll apply smaller set of changes with each patch (one changeset's, not the whole range)
    – Lazy Badger
    Commented Oct 21, 2016 at 12:06
  • I don't follow; the whole range of what? A rebase replays a single set of previously committed changes, one at a time, then stops.
    – IMSoP
    Commented Oct 21, 2016 at 12:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.