Open Bug 1725330 Opened 3 years ago Updated 1 month ago

Please add something like "first version without this line" for lines that are removed in the future

Categories

(Webtools :: Searchfox, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: glandium, Unassigned)

References

Details

Example of workflow where it would have been useful:

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.

See Also: → 1517978

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.

Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Assignee: bugmail → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.