2

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 '15 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 '15 at 0:42
  • Also: commit --amend --all --reuse-message=HEAD – Johnson Jul 22 '15 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. – David Hammen Jul 22 '15 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 '15 at 10:57
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)
1

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 '15 at 10:57
  • Please stop using MQ. – Kevin Jul 22 '15 at 12:13
  • Yes you can use the histedit command instead of MQ. – sylvanaar Jul 22 '15 at 13:20
  • I use MQ because TortoiseHG has a nice interface for it. – sylvanaar Jul 22 '15 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 '15 at 21:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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