2

We're using Kiln and Fogbugz; Kiln is supposed to seamlessly allow git and hg to work together. However, we've run into an issue where git branches are treated like bookmarks in mercurial; we didn't catch this in our repo until changes had been pushed, and now the branches are a bit polluted.

I have public changesets in our default branch that should be in a custom branch. I can back them out, but I need to reapply them to the other public branch. I'm worried about rebasing because these are public changes.

What's the best way to handle this situation?

Edit: I thought I might be able to convert the changesets to a patch using mercurial queues, but the changesets aren't mutable since they're public. I also can't do hg strip for similar reasons.

George Mauer
  • 117,483
  • 131
  • 382
  • 612
  • The closest analog to Git branches in Mercurial [is bookmarks](http://mercurial.selenic.com/wiki/Bookmarks/), so it is not surprising that this happened. From the article, "Mercurial's bookmark feature is analogous to Git's branching scheme". – ChrisGPT was on strike Apr 15 '14 at 19:42
  • 3
    I don't know the *right* way to do all this but for my particular purposes, when Mercurial thinks changesets are public but I know it's OK to strip them, I just use `hg phase -d -f -r ...` to force them back to draft phase. – torek Apr 15 '14 at 19:42
  • I only have Git expertise, not Mercurial or Kiln, but I just want to point out that rebasing public Git commits ***is generally feasible***. The main point of concern with it is how difficult it is for people who have the old commits to re-sync their work with the new ones. If you have a small team that is skilled with Git, this shouldn't necessarily be an obstacle that couldn't be overcome with a reasonable amount of effort. –  Apr 15 '14 at 20:03

2 Answers2

1

In Mercurial, you use hg graft to copy (also sometimes called cherry pick) changesets from one place to another. It is frequently used to backport a bugfix to a maintenance branch when the bugfix was committed on the wrong branch by accident.

You use it like this:

$ hg update correct-branch
$ hg graft your-commit

This will recreate your-commit as a child of correct-branch, similarly to importing your-commit into MQ, popping the patch, updating to correct-branch and pushing the patch. The advantage of graft is that it will use three-way merges internally to give you much better conflict resolution. It is really the same way that hg rebase works.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
  • Marking this as correct. Although I didn't use this technique to solve my issue, I'm sure it will come in handy in the future. –  May 26 '14 at 16:52
0

I'd like to promote torek's comment to a full-fledged answer to make it more visible.

As he notes, the hg phase command (with the --force flag) can repair the situation when mercurial thinks the changeset has been made public. Of course you want to make very sure you're right about whether it has been shared first.

I ran into a glitch where mercurial marked an unpushed branch as public, and this made it easy to fix with qimport (or could have used strip.)

Joshua Goldberg
  • 5,059
  • 2
  • 34
  • 39