1

I'm currently dealing with the fallout from BitBucket dropping HG support. We're going to be giving hg-git a try because, while my preference is self-hosting, my boss isn't quite mad enough at Atlassian to move away from BB yet. Taking this opportunity to clean up our existing HG repo before the conversion to GIT. Have used hg convert to remove some accidentally committed binaries to reduce size, etc.

One thing I've noticed is that we've got about two dozen old branches that are technically "open", but have been merged into default (no closing commit, but they're months to years old). Is there any way I can use a tool like hg histedit or during the hg convert to go back and specifically mark old branch heads with --close-branch?

Looking through docs I can find things about editing files, editing the contents of commits, or modifying commit messages, but nothing I can find mentions meta-data around whether a commit is "closed". I know this is just a flag on a given commit, but I don't know how to retroactively add it via any HG extension.

Edit: Just to add a bit more clarity, I recognise I can just update to each of these old branches & add a new commit that just closes the branch. There'll be a lot of dangling-looking, closed heads, but that'd work fine enough. However, I also then have to give each of them a bookmark in HG as well, or these additional "closing" commits are lost in the hg-git conversion. I'd rather avoid having to add ~30 additional branches to the git branch-list, just to have them show up as closed properly in HG without having to use revsets.

What I want to do isn't "essential" in the grand-scheme of the repo, but I'd be surprised if editing a commit's metadata to say --close-branch were impossible.

Lovethenakedgun
  • 731
  • 6
  • 22
  • you can check the closed state of heads without any extension via `hg heads --closed` (only heads can be closed) – planetmaker Jan 13 '20 at 09:32
  • Sorry that I wasn't clear in the question, @planetmaker. I'm talking about old branch heads that have been merged in. I want to *retroactively* mark these commits with the "closed" flag, so they don't show up in things like TortoiseHg's branch list (though I know I can actively filter them out via a rev-set). – Lovethenakedgun Jan 13 '20 at 09:36
  • have you then considered to use the `--topo` flag, e.g. `hg heads --topo`? That gives only heads without children, thus excluding merged heads. – planetmaker Jan 13 '20 at 09:37
  • Wasn't aware of that flag, pretty useful. However, this has less to do about "finding heads" at the command-line level, and more to do with repository consistency & expectations of defaults (e.g. TortoiseHg's default branch list). For certain scripts I've been using things like, `hg log -r "head() and not(closed()) and sort(date('>$date'))" --template "{branch}\n"` to filter out these old edge-cases; but I'd rather correct them than filter them out, given I have to rebuild the repo now anyway. – Lovethenakedgun Jan 13 '20 at 09:49
  • I haven't tried this myself, but could you retroactively add a close branch, and then rebase the original merge to default so that it follows the closing? Since you are rebuilding the repo you can rebase in a way that you wouldn't normally do for published changes. – StayOnTarget Jan 13 '20 at 16:04
  • K, thanks for the suggestion @UuDdLrLrSs, but I wasn't able to get this to work-- not sure if this has to do with the rebasing itself or my lack of knowledge. Tried with a new, simple repo. Trying to rebase the "closing" head, but it ended up basically trimming it instead. Tried a few other things, but ended up just mangling the test repo. – Lovethenakedgun Jan 14 '20 at 00:58

1 Answers1

2

I tested out the rebase idea with a mock repository and it seemed to work.

Here was the starting repo:

enter image description here

And here was the state after rebase:

enter image description here

I think this example matches what the question was asking about. The original dangling close-branch changeset was moved to precede the merge.

I updated to default and ran the following command:

hg rebase --dest=4 --source=3 --keepbranches --config=ui.merge=internal:merge

I actually used Tortoise Workbench to execute the rebase and that is the command it used. So the final argument for ui.merge is probably not strictly necessary.

As you may have already noticed using hg convert its a really good idea to make new clones when you go to modify the repository. Thus if it gets messed up you have an easy undo option. I'd certainly recommend that approach for this operation as well.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
  • Ok, still the best answer; worked for simple case, but not ideal. HG seems to rebase every commit between source and destination. In the example, the difference is small, but my command was: `hg rebase --source=35 --dest=2999 --keepbranches --config=ui.merge=internal:merge` & I gave up and killed it after an hour (50% done). Also, without that config option, I had to manually approve each kdiff3 merge on my machine; setting seems to try and automatically resolve merge conflicts. Not much should change post-rebase, but lots of merging/rebasing is happening in the log; need to do this quicker. – Lovethenakedgun Jan 16 '20 at 03:32
  • @Lovethenakedgun it may not make enough difference to be worthwhile, but you can change some settings to make rebase run a lot faster - at least if it doesn't run into conflicts (which it shouldn't in this case) - https://stackoverflow.com/a/55403657/3195477 In my experience this does speed it up quite a bit. – StayOnTarget Jan 16 '20 at 12:23