It looks like if the ;<commit hash> exits, diffusion ignores the master part:

https://secure.phabricator.com/diffusion/P/browse/green-eyed-monster/src/applications/search/engine/PhabricatorApplicationSearchEngine.php;bdef125

so the work-around should work even if the commit is not present in master.

Although I think the old version makes more sense than this one.

I hadn't tried to test that! You appear to be correct.

I think the original form only worked by accident, we don't use it in the UI anywhere. This behavior likely changed when I fixed T7100.

Specifically, we now require the ref part of the URL (normally /master/ or similar) to correspond to an actual branch or tag. Previously, we'd accept a ref that resolved to anything, but badly mishandled cases with ambiguous refs, especially multiple heads in Mercurial.

To handle this case and treat ambiguous refs correctly, we'd need to do a moderately large amount of work so we could present a choice when you browsed to /cf813fd0.../ and that was a commit hash and also either a tag name (in git) or branch name (in git or mercurial). This complexity doesn't seem worthwhile since it isn't very useful in general: we'd be doing a lot of work to support this very niche case.

We could have some kind of token which means "use the configured default". This seems reasonable, although Mercurial branch names permit so many special characters that it may be difficult to select a suitable token which can't also be a valid ref name. It probably has to be some kind of ASCII-art monstrosity like ~^:default:^~.

We could provide a different command word, like /browse-on-default/.

Both the special token and special command word approaches suffer from being difficult to discover.

If you want to pick some unobjectionable "default" token which is not a valid tag or branch name in Git or Mercurial (and, ideally, unlikely to ever be a valid ref in any VCS) I'm happy to implement that and shove it in the documentation. Not great, but seems least-bad to me.