Example of workflow where it would have been useful:

• Start from https://searchfox.org/mozilla-central/rev/3a8091d1c29473a0839ad7a5810028f41363fe2e/dom/media/webrtc/transport/third_party/moz.build
• Hover line 24 and use "Show earliest version with this line".
• Now you realize there's a bunch of stuff that was added at the same time that's not there anymore.
• It would be useful to be able to find the version that removed these lines.

Yeah, this would be very handy. Right now the blame mechanism fundamentally only points backward in time based on how the pre-computation/caching works. (Details at https://github.com/mozsearch/mozsearch/blob/master/docs/blame.md.)

If anyone's thinking about an extensive overhaul of blame, it's likely worth also considering switching to the microannotate model discussed from https://bugzilla.mozilla.org/show_bug.cgi?id=1517978#c2 onwards which can do a better job of resisting refactorings/style changes.

I think I know how to address this use case in a slightly different form as part of my experiments on bug 1517978. The basic idea would be to have a "follow these lines forward in time" (or more pedantically, follow this set of tokens forward in time). This works for several use-cases:

• The mercurial web UI feature where you can select a range of lines and follow them forward or backward in time, showing each hunk that overlaps the line set, with the notable side effect that I believe the range of lines being followed is effectively unioned with each hunk and everything is line-centric rather than token-centric.
• A much improved "Go to latest version" feature for searchfox. Right now we just drop the revision hash and use the existing line number, which mean your line number is going to be wrong unless there have been no changes to the file. If we actually followed the line/its tokens, we can save the user some find-in-page-ing as well as potentially show a (collapsible) history summary of what changed in the file in between the permalink revision and the current HEAD.
• This use case, with the big caveat that we wouldn't know when first showing the UI that a set of tokens was doomed. However, it's also the case that what I'm hacking on potentially can track a token change due to a rename, so showing a history of changes is quite potentially more useful as there's a good chance the user might have just been using searchfox's blame functionality to establish such a timeline themselves.
  • That said, one thing we could do is have a bit of a "future overlay" that could be triggered for the code visible on the screen or in a specific selection of lines and which would, instead of showing a sequential history timeline could instead visually distinguish all the tokens that will be removed by applying a strikethrough or colorizing their background based on how long the code lasts before it gets removed in the future. This would use the same core traversal logic under the hood despite the rather different UI.

Assigning to myself for now to avoid effort duplication and in case anyone wants to chime in with thoughts on this potential feature.