Page MenuHomePhabricator

Improve handling of ambiguous branch references (tags/branches with the same name, multiple branches heads)
Closed, ResolvedPublic


  • In Mercurial, it's possible to have multiple branch heads with the same name.
  • In Git, it's possible to have multiple symbols (e.g., a tag and also a branch) with the same name.
  • The UX these cases is bad.
    • We don't degrade gracefully (we should select the best alternative and continue).
    • We conflate "missing" and "ambiguous" references, but these are significantly different.
    • We don't present the error in a helpful way.

I am getting the 'Ref "default" is ambiguous or does not exist' error in one of my Mercurial repository after updating PH to latest. I went thru the commits and manually undo commit d98eb2c to get PH back up and running.

I think the issue is because there are multiple "default" branches in my repository. I am not sure how that is even possible as it was before my time. I "think" we were using subrepository at that time so maybe that's why there were multiple default branches inside a repo.

capture1.png (464×974 px, 56 KB)
Capture2.png (508×1 px, 184 KB)

Event Timeline

wokuku raised the priority of this task from to Needs Triage.
wokuku updated the task description. (Show Details)
wokuku added a project: Diffusion.
wokuku added a subscriber: wokuku.
chad renamed this task from Getting 'Ref "default" is ambiguous or does not exist' error to Getting 'Ref "default" is ambiguous or does not exist' error (multiple default branches).Feb 1 2015, 7:47 PM
chad reopened this task as Open.

I could get around the problem by setting my default branch to something other than "default", as suggested in the other task. But the "default" branch is really our default branch and i would really like to show changes there as default.

I should also go look at why we have that many "default" branches and see if there is a way to clean those up

epriestley added a subscriber: epriestley.

Yeah, this is not quite the same as T7085.

In Mercurial, branches may have multiple heads, so a branch like "default" can resolve to several different commits. Although I personally believe this feature is crazy, it's explicitly supported in Mercurial and we should support it in Diffusion.

That said, use of this feature is rare and maintaining a repository with multiple heads on the "default" branch for a long period of time is especially unusual, so this is hard to prioritize and it will probably be a while before we can fix it.

I had this same issue, but there was only one not-closed default branch. Maybe just not show closed branches?

Also: I'm fairly sure you can't push multiple heads? At least, I've tried but always got an error because I was trying to create new heads in the remote which wasn't allowed.

You can push them with hg push --force. For hosted repositories, we additionally flag such changes as "Dangerous", so you have to enable "Allow Dangerous Changes" in the repo settings or we'll stop you. See D7763.

Aside from hg push --force you can also push multiple heads when using bookmarks, if you use hg push -B my-bookmark

epriestley renamed this task from Getting 'Ref "default" is ambiguous or does not exist' error (multiple default branches) to Improve handling of ambiguous branch references (tags/branches with the same name, multiple branches heads).Apr 24 2015, 7:23 PM
epriestley claimed this task.
epriestley updated the task description. (Show Details)

I think this is in mostly reasonable shape now, but let us know if there are still issues.

Our repo has 4 closed branches and 1 open (being 'default'). The main repo page no longer shows the closed branches, but when viewing all branches, it looks like several are listed twice with different repo heads.

Screen Shot 2015-04-27 at 10.33.44 AM.png (314×895 px, 77 KB)

[cspeck@repo MS]$ hg branches -c
default                    93616:fade3df180a2
mim_4.2.0                  88329:eed05955c3cc (closed)
mim4x_trunk                88328:4dad86161093 (closed)
mim_4.1.0                  88325:02073e640fc3 (closed)
mv_1.1.0                   88324:d6e2fa29ad23 (closed)

Does hg log --rev 'head()' give you the other heads?

Yes it lists all the ones phabricator shows.

I'm guessing hg heads -c will also show them.

I'm not immediately sure what causes heads to appear in hg heads -c but not in hg branches -c.

Yes they all show under hg heads -c as well. Looks like everything is set then as apparently there are multiple heads for the same branches, but all closed.

I think hg branches just picks one head to show when there are multiple heads of a branch. For example, if you're on rev 9 and hg up 8, then make a commit (creating a second local branch head for default), the hg branches command still shows only one head, even though your working copy has multiple open heads of the branch.

From a little poking around, the rule might be to show the head with the largest local revision ID.

I think it's reasonable that we show data similar to hg heads in the full branch list instead of data similar to hg branches, even though this is a little counterintuitive -- especially if the rule really is "local rev ID", which isn't very meaningful in a remote. We could maybe add some options to the branches table eventually to let you filter things (show only open heads) or group them (show one record per unique branch name, like hg branches).

I have no immediate desire for the branches listing to resemble hg branches, I was just confused at the difference in output. I didn't realize the closed branches had multiple heads in my own repository :).

When using Mercurial, can Diffusion handle multiple remote bookmarks on the same branch?

We've had an issue where Diffusion has not been usable for a couple of years, as it seemed to have gotten "stuck" on a particular commit. Upon further investigation today, it appears to have happened since we use remote bookmarks (instead of branches). So there are multiple bookmarks and heads in the default branch, which seems to be confusing Diffusion.

What can be done if we're using remote bookmarks in the same way one would have been using git branches? Is this use case not supported in Diffusion?