Diff for "BlamePlan"

This page documents potential improvements to blame/annotate functionality.

Separate blame algorithm from presentation code

Currently, the low-level annotate function lives in context.py. Formatting of things like line numbers also occurs inside the function. There needs to be a refactoring to separate concerns.

hgweb links to ancestor's blame

Often when people use blame, they want to trace a file or block's history back through time. It is difficult to do this on hgweb (or via the CLI for that matter) today. Adding a link to hgweb that loaded the blame for the same line on the nearest ancestor changeset that modified that line/block would be a massive time saver.

hgweb links to changeset

Currently the links next to the code in the blame view links to the diff for the particular file. It would be more useful to link to the changeset which changed the given line since the changeset page contains more contextual information. So rather than link to <repository>/diff/<changeset>/<filepath>, link to <repository>/rev/<changeset>

Ideal would be to link to the changeset page, but to the line which added/changed the given source line. I.e. to <repository>/rev/<changeset>#l<line>

Keyboard shortcuts on hgweb

Adding keyboard shortcuts to hgweb for navigating blame could be very useful.

Calculate blame from tip to base

Currently, blame is calculated by starting at the base revision and applying deltas until you get to revision being blamed. It might be faster to calculate blame by starting at revision being blamed and apply reverse deltas until all lines have a revision attached.

Automatically skip revisions

It would be nice if you could easily configure blame to ignore certain changesets or types of changes. e.g. whitespace only changes, manually specified revset.

Preserve data for each revision

Currently, calling annotate() returns results for the requested revision and nothing else. Internally, annotate() builds up state for multiple revisions before returning the state of the requested revision. If we preserved this old state, we could do things like send it to consumers that are capable of storing every revision and quickly cycling between them.

See also the advanced HTML interface below for ideas on how this data could be used.

Advanced HTML interface

If hgweb exposed websockets or some other streaming protocol for receiving blame data, we could construct an advanced blame viewer that incrementally loaded blame information and allowed quick navigation between revisions. For example, the page could start by rendering the plain file content with no blame information. In the background, a websocket request starts receiving blame information for every revision of the file. As the blame information is received, the per-line/block blame information is updated and the browser stores a copy of the history of blame. A horizontal slider could be used to rapidly switch between revisions. These wouldn't require round trips to the server because the browser has already stored/cached blame information on multiple revisions.

It has been suggested to investigate :Gblame from fugitive.vim for ideas worth borrowing.

grep + blame

Add the ability to do a grep-like search + blame output. Use case is you are looking for a particular fragment of code but you also want to see blame / context around that line for revisions that changed it.

Reverse blame

In "reverse blame" mode, one can easily find when a line in an old revision was modified or removed in a newer revision. This could be a link or mode in the HTML interface to quickly go the other direction.

Visual grouping of changesets

Typically there are block of lines all attributed to the same revision. Instead of rendering the revision/changeset for every line, we could only render it once per block.

Hover info box for changeset info

The per-line changeset info is very sparse. Perhaps an info box which renders more details could be rendered on hover. 3rd parties could extend the info rendered to e.g. include links to bugs.

CategoryNewFeatures