On 06/12/2013 05:55 PM, Julian Foad wrote:
Markus Schaber wrote:
On Mon, Jun 10, 2013 at 01:38:48PM -0000, danie...@apache.org wrote:
It would have been easy to find what revision removed the line break if we
had a reverse blame --- that is, a blame that walks the chain of diffs from
newerto older, rather than from older to newer.
+1
While we're talking about blame improvements, another one is blame a line
range: stop as soon as every line in a given [X, Y] range is accounted for
(use-case: svn blame | grep -5 '/line I am looking at/'). Bert says that
stop as soon as "at least one" line in a given range would be useful for
him (use-case: "which revision last changed [this function definition]?")
and suggests that API users would find a callback that allows them to decide
when to stop gathering further blame information.
Agreed.
May be this way also allows to do queries for deleted lines by making the
callback stop when he finds a deleted line in a given range.
I have thought before that it would sometimes be useful to include blame
information on the gaps between lines. For each gap between adjacent lines
(and before the first and after the last line), there is a revision in which
any text between these two lines was deleted.
Example: blame -r1:30 foo.c@30 could produce these (revnum | line-text) pairs:
r20 | "int main()"
r20 | "{"
r25 | NULL
r30 | " return 0;"
r20 | "}"
where NULL means some line(s) were at this position in r24 but nothing was here
in r25 up to the revision being blamed.
- Julian
How would we handle/show if the line existed in 24r but not in r25..
Again existed in r27 and removed in r29 ? I can't think of the UI...
--Prabhu
