When I'm on a git project, I have a workflow that goes something like this:

  1. Start a new feature (open a new branch)
  2. Write some code, commit some code, repeat
  3. Push the code to a remote, possibly with my initials in the branch name, and 'WIP' commits, indicating that it's unfinished
  4. Once things start taking shape, squash commits together, change their messages, delete them, rearrange them, etc.
  5. Keep working
  6. Decide things are ready for review, submit a pull/merge request (possibly after force-pushing to destroy my old, work-in-progress, branch)
  7. Get some review, put more changes that came from that review on top
  8. Get approval to merge the branch
  9. Merge the branch. Bask in the beautiful history of the feature it is that I just merged, but never rewrite history on the master/default branch (unless I'm the only one on the project)

Is this workflow supported in mercurial? How about without plugins? I'm fairly new to mercurial, but I know enough (and lean on this cheatsheet enough) to get what I want to get done. However I'm not able to use this workflow. There is much care in crafting the perfect commit, and just piling stuff on top of it because otherwise I seem to get error messages. This seems to be by design, but I'd really rather use my workflow for my branches.. and then conform to the type of history management (e.g. merges/rebases/no rewriting) for branches that many people work on.

  • 1
    There is this StackOverflow answer pointing to a Collapse Extension, though I have no idea if this is the best possible solution within Mercurial.
    – Ixrec
    Jul 21, 2015 at 23:26
  • Some git commands that might be used in this workflow: rebase --interactive, push --force, pull, fetch, merge --ff-only, reset --hard, possibly others?
    – Johnson
    Jul 22, 2015 at 0:42
  • Also: commit --amend --all --reuse-message=HEAD
    – Johnson
    Jul 22, 2015 at 1:44
  • 1
    Mercurial is aimed for ease of use. Don't fight it. Do not try to do that rebase --this-option --that-option --yet-another-option nonsense with hg. Just let it do it's thing. The git penchant for hacking history targets one specific project that involves thousands of developers spread across the globe. Unless you are contributing to that singular project, the standard git workflow <expletives deleted>. In my opinion, of course. Actually, not just my opinion. The developers at github eschew that git workflow for a workflow that makes gitflow look complex. Jul 22, 2015 at 4:12
  • 1
    @DavidHammen: A simple "no, it won't support your workflow without extensions that work outside the repository" will suffice. If it's inflexible I'll just have to learn the mercurial way of working. For more info on GH flow see guides.github.com/introduction/flow/index.html
    – Johnson
    Jul 22, 2015 at 10:57

2 Answers 2

  1. If you exclude p.3 from your workflow (can't see strong reasoning for this operation) and slightly change related p.6 , you can migrate full cycle to Mercurial "as is"
  2. Even if MQ noted as "feature of last resort" it can be useful tool (probably paired with MQCollab extension) for your "must to be shared" WIP (is it really must be shared even in dirty chaotic state?!)
  3. Manipulating history for non-published changesets is really easy task in Mercurial (at least not harder and not weaker, than it Git)

Firstly, you will be working on the default branch most likely.

You can create a bookmark for your "branch"

You can push that bookmark to another repository. People can look at it.

When you are ready to rewrite the history you would use the MQ extension.

You can pop off all the changes you want to rewrite, change their commit notes, squash them together, then reapply them.

When you are done, delete the bookmark from the remote and create a new bookmark

Unfortunately this will leave a dangling head, you will have to run a strip command on your local and remote and on any repo that pulled in your "branch" to get rid of the old "branch"

When you are ready to merge push your bookmark and ask that it be merged with the main head of the default branch.

It's a really awkward workflow for HG because it creates lots of heads that require stripping.

  • Thanks for the answer! I'll have to learn MQ. Last time I tried I ended up having to delete and re-clone, and was told on irc that I shouldn't be using it because it "works outside the repository". I didn't know this was possible. Other possibilities/suggestions :)?
    – Johnson
    Jul 22, 2015 at 10:57
  • Please stop using MQ.
    – Kevin
    Jul 22, 2015 at 12:13
  • Yes you can use the histedit command instead of MQ.
    – sylvanaar
    Jul 22, 2015 at 13:20
  • I use MQ because TortoiseHG has a nice interface for it.
    – sylvanaar
    Jul 22, 2015 at 13:26
  • @Kevin THANK YOU. That link was extremely helpful. I may become a mercurial user yet :). In fact that whole blog is filled with good stuff.
    – Johnson
    Jul 22, 2015 at 21:22

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.