1871497 - Provide github revision control links for the various submodules of mozilla-mobile

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

Memorializing a discussion about mozilla-mobile, :RyanVM requested that the navigation panel provide revision control links for the sub-repos of mozilla-mobile.

This is potentially related to :kats' proposals in bug 1493422 about doing better for blame for vendored code.

The mozilla-mobile case, however, is of course a much simpler situation where we could also just define a concept of a "composite" (synthetic) tree where we could have special logic that recognizes that the immediate children of the source root are actually separate subtrees and we could just have separate "git" and "blame" subdirs for them. If we did that specialization for composite trees, we could do away with the synthetic root git tree that creates submodules and creates a complicating linearization of the tree histories.

This could allow, for example, for having an aggregated "standards" composite synthetic repo which could track the specs listed at https://github.com/w3c/browser-specs and while this could provide for a unified search experience, it would allow the repository histories to be entirely orthogonal, avoiding creating situations where we need to potentially do expensive blame history regeneration every time a new spec is added (since those specs would almost certainly have history extending prior to the day when they were added to the browser-specs repo).

A baby step of just having links to the tip revisions of the files would be to add entries to https://github.com/mozsearch/mozsearch/blob/master/config_defaults/per-file-info.toml and supporting logic to https://github.com/mozsearch/mozsearch/blob/master/tools/src/file_format/per_file_info.rs that would apply metadata to files based on their path. Given that we explicitly have a .gitmodules that effectively provides the mapping, this could be reasonably straightforward. The main complication is that the submodule file is very much not valid TOML, but it wouldn't be hard to use an ini parsing crate or just make a shoddy one that's intentionally brittle. Or I see there's an https://github.com/justinmk/tree-sitter-ini (not yet on crates.io) which might be useful to use for history purposes.