Gregory Szorc a écrit :
On Sat, Feb 25, 2017 at 1:06 AM, Denis Laxalde <de...@laxalde.org> wrote:
# HG changeset patch
# User Denis Laxalde <denis.laxa...@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 :)
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
