[PATCH 8 of 8 V2] hgweb: add a "followlines" link to hover-box in annotate

Denis Laxalde denis at laxalde.org
Wed Mar 1 10:52:06 UTC 2017


Gregory Szorc a écrit :
> On Sat, Feb 25, 2017 at 1:06 AM, Denis Laxalde <denis at laxalde.org> wrote:
>
>> # HG changeset patch
>> # User Denis Laxalde <denis.laxalde at logilab.fr>
>> # Date 1487773255 -3600
>> #      Wed Feb 22 15:20:55 2017 +0100
>> # Node ID f1d1d7bcba3cd86787117cd44616ad1a5c619c5e
>> # Parent  073bd73b65afcb2acd4783c14cb2983ef21fb5a6
>> # Available At https://hg.logilab.org/users/dlaxalde/hg
>> #              hg pull https://hg.logilab.org/users/dlaxalde/hg -r
>> f1d1d7bcba3c
>> # EXP-Topic linerange-log/hgweb-filelog
>> hgweb: add a "followlines" link to hover-box in annotate
>>
>> The hover-box on line numbers in annotate view now holds a "follow lines
>> <fromline>:<toline>" link where '<fromline>:<toline>' corresponds to the
>> range
>> of line numbers annotated by a given revision. This link points to the
>> filelog
>> view where the log is filtered to only include revisions changing the line
>> range at stake (through `?linerange=<fromline>:<toline>` query parameter).
>> From this view, one can follow "diff" links which also points to filediff
>> view
>> with only selected line range visible.
>>
> I'm going to gently push back and question the utility of this feature.
> First, obviously there are some killer features for looking at history of a
> range of lines. But I'm questioning whether this specific implementation
> adds enough value.

I'm glad you do this since I wasn't myself much convinced of the added
value of this feature. This is just the simplest way of exposing the
"URL-based API" introduced in previous patches that I could think of at
the moment and I did not want to invest more in something fancier before
having discussions.
(Basically "forgot" the trailing (RFC) in commit message's first line.)

>
> The annotate hover box as implemented in this patch links to a page showing
> a list of revisions touching those lines. That's useful. But I argue it is
> less useful than the following alternatives:
>
> * Show history for just this line
> * Show history for this function
> * Show history for a range of lines I specify
>
> The reason is (and this could just be my own experience biasing me) that
> the annotate block rarely maps to the unit being investigated when doing
> code archeology. When I'm looking at the annotate history of a file, I'm
> usually investigating a specific line, function, or range of lines. The
> annotate blocks don't map cleanly to those because in well-established
> files with lots of history, the annotate blocks are effectively random
> noise in terms of lines they cover. So with this implementation, there are
> many scenarios where the line range block is too small or too wide.
>
> I suppose looking at the line history of an annotate block is better than
> nothing and you have to start somewhere. But there are far more useful
> implementations IMO.

I totally agree.

I think one way to achieve a more interesting exposure of this feature
would be to start from /file/<rev>/<filepath> view and have a way to
select a range of lines.
One simple thing would be to implement form with two <select> elements
in the header of the view. This my second choice for a "quickstart"
implementation because I though having a form on top of the page would
require too much scrolling and line-counting.
One fancier idea would be take advantage of highlighting with pygments
to let the user select the range of lines based on language tokens (not
sure how big this task would be though).

> Also, the page it links to showing the revisions with links to a line range
> filtered diff is good but not great. I imagine developers will complain
> that it requires too many clicks to go to what they want (the actual line
> content). IMO it would be *really* useful if there were a single page
> showing multiple changesets and line range data for either/and a) raw line
> content b) annotate view c) diff view. That way, developers could scroll
> and see all versions of that line range. If you were looking at say the
> history of a function, this would be *extremely* useful compared to loading
> N pages. This improvement could be done as a follow-up and doesn't need to
> block this series.

I can work on a ?patch=1 URL API (mimicking `hg log -p`) that would
indeed be useful in this context.

>
> Again, this is great work and this is going to be a great feature. When
> this is complete, I anticipate the feature being stolen by Bitbucket,
> GitLab, GitHub, and others, as it is really a killer feature for code
> archeology.
>

Thanks :)



More information about the Mercurial-devel mailing list