Bugzilla

Thanks!  I think I switched to scanning that section when I originally read the post when I got to the shell invocations and my brain didn't switch back to full reading until the next header.

The most pragmatic option is probably then that when we get to phase two from the [announcement](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/QnfydsDj48o/m/8WadV0_dBQAJ) we:
- create a new searchfox tree we'll speculatively call "gecko" and point it at the new github repo.  It is configured to not be aware of mercurial as a thing.  Presumably we'd create "gecko-beta" and "gecko-release" as well when the branches are cut and then "gecko-esrNNN", etc.
- leave mozilla-central running like it is, fetching from hg.mozilla.org using cinnabar.  This would stop updating when hg.mozilla.org gets turned off, although some minor shell script fixes might be required if treeherder's "mozilla-central" tree is changed rather than a new git-using tree with a new name brought online.

This avoids needing to complicate searchfox to be able to understand revisions as having an hg rev, a git rev, and a different git rev while not breaking existing permalinks.  Also, we can avoid having to get clever in any of our shell scripts; we just fork everything in [mozsearch-mozilla/shared](https://github.com/mozsearch/mozsearch-mozilla/tree/master/shared) for the new tree scripts to "gecko-shared".  Also the new trees can be brought up experimentally in a decoupled fashion.

Thanks!  I think I switched to scanning that section when I originally read the post when I got to the shell invocations and my brain didn't switch back to full reading until the next header.

The most pragmatic option is probably then that when we get to phase two from the [announcement](https://groups.google.com/a/mozilla.org/g/firefox-dev/c/QnfydsDj48o/m/8WadV0_dBQAJ) we:
- create a new searchfox tree we'll speculatively call "gecko" and point it at the new github repo.  It is configured to not be aware of mercurial as a thing.  Presumably we'd create "gecko-beta" and "gecko-release" as well when the branches are cut and then "gecko-esrNNN", etc.
- leave mozilla-central running like it is, fetching from hg.mozilla.org using cinnabar.  This would stop updating when hg.mozilla.org gets turned off, although some minor shell script fixes might be required if treeherder's "mozilla-central" tree is changed rather than a new git-using tree with a new name brought online.
  - A minor enhancement we can make is to be able to configure the mozilla-central search box at the top of any m-c pages to reference the new gecko tree so that people don't end up accidentally searching in a stale tree since the m-c tip would eventually be a footgun.  This could also affect the file path breadcrumbs too.  Probably the "go to latest revision" link would also do well to bounce to the new tree too.  (Go to latest revision is not currently able to follow renames/copies; I have some WIPs working towards that, but the "legacy tree forwarding" feature would probably disable that or just tunnel the information to the new tree if we ever get a hash translation layer.)

This avoids needing to complicate searchfox to be able to understand revisions as having an hg rev, a git rev, and a different git rev while not breaking existing permalinks.  Also, we can avoid having to get clever in any of our shell scripts; we just fork everything in [mozsearch-mozilla/shared](https://github.com/mozsearch/mozsearch-mozilla/tree/master/shared) for the new tree scripts to "gecko-shared".  Also the new trees can be brought up experimentally in a decoupled fashion.