Re: Improving blame in Mercurial

[smaug]

On 01/04/2016 07:43 PM, Robert Kaiser wrote:

Gregory Szorc schrieb:

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let
me know by replying to this message. Your feedback will be used to drive
what improvements Mercurial makes.


I really liked a lot about the blame implementation that bonsai had, 
unfortunately we don't have a running copy any more AFAIK so it's hard to take a
look at it.

For one thing instead of showing author and changeset (or version in CVS) for 
every line, it grouped subsequent lines changed at once together and
showed that information only once for them.
For the other, when you moved your mouse over that author/changeset "blame" 
info, it didn't just show a tooltip but a full-fledged HTML box where e.g.
bug numbers in the checkin comments could be linked and you could call up that 
link (in a new tab probably) right away and directly go to read the bug
that changed this code.


Indeed, bonsai had the best blame UI I've ever used, tough even that could have 
used some ux help. But at least it was efficient.
Comparing to ViewVC for example Bonsai needed 1 click vs ViewVC's 6 to get to 
the relevant bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=1200362#c5
hg annotate takes 3 clicks.
Since each click means a page load, optimizing that would be great.





Those two features would be great to see in hg blame/annotate as well.

KaiRo



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Jonas Sicking]

On Tue, Jan 5, 2016 at 9:57 AM, smaug  wrote:
>> I really liked a lot about the blame implementation that bonsai had,
>> unfortunately we don't have a running copy any more AFAIK so it's hard to
>> take a
>> look at it.
>>
>> For one thing instead of showing author and changeset (or version in CVS)
>> for every line, it grouped subsequent lines changed at once together and
>> showed that information only once for them.
>> For the other, when you moved your mouse over that author/changeset
>> "blame" info, it didn't just show a tooltip but a full-fledged HTML box
>> where e.g.
>> bug numbers in the checkin comments could be linked and you could call up
>> that link (in a new tab probably) right away and directly go to read the bug
>> that changed this code.
>
> Indeed, bonsai had the best blame UI I've ever used, tough even that could
> have used some ux help. But at least it was efficient.
> Comparing to ViewVC for example Bonsai needed 1 click vs ViewVC's 6 to get
> to the relevant bug.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1200362#c5
> hg annotate takes 3 clicks.
> Since each click means a page load, optimizing that would be great.

I generally agree. Especially about Bonsai, though far from perfect,
being the best UI I've personally used.

Though I'd be careful to simply measure number of clicks. Bonsai
required a lot of swooping and hovering, which also adds to the effort
of reaching information.

For example, clicks which display information in-page can be made a
lot faster than ones that navigate, so that might be an option to
consider as well.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Ehsan Akhgari]

On Mon, Jan 4, 2016 at 9:33 PM, Ehsan Akhgari 
wrote:

> On 2015-12-11 6:28 PM, Boris Zbarsky wrote:
>
>> On 12/11/15 6:17 PM, Gregory Szorc wrote:
>>
>>> If you have ideas for making the blame/annotate functionality better,
>>> please capture them at https://www.mercurial-scm.org/wiki/BlamePlan
>>>
>>
> This is a great plan!  I'm excited to use this, I have never seen a good
> web-based blame UI.  :-)
>
> In case you haven't seen it yet, please checkout :Gblame from
> fugitive.vim: I find its interface quite usable, by letting you select a
> commit and display it in a bottom pane.  This plus going to the blame on
> the parent commit (using a keyboard shortcut) actually makes blaming fun!
> I think we can get some good ideas from it for the advanced UI mentioned in
> the wiki.
>

I meant to include a screenshot: <
http://f.cl.ly/items/070G0J0P3T0O3G2u2f0i/Screen%20Shot%202014-02-07%20at%203.38.20%20PM.png
>

-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Ehsan Akhgari]

On 2015-12-11 6:28 PM, Boris Zbarsky wrote:

On 12/11/15 6:17 PM, Gregory Szorc wrote:

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan


This is a great plan!  I'm excited to use this, I have never seen a good 
web-based blame UI.  :-)


In case you haven't seen it yet, please checkout :Gblame from 
fugitive.vim: I find its interface quite usable, by letting you select a 
commit and display it in a bottom pane.  This plus going to the blame on 
the parent commit (using a keyboard shortcut) actually makes blaming 
fun!  I think we can get some good ideas from it for the advanced UI 
mentioned in the wiki.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Robert Kaiser]

Gregory Szorc schrieb:

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let
me know by replying to this message. Your feedback will be used to drive
what improvements Mercurial makes.


I really liked a lot about the blame implementation that bonsai had, 
unfortunately we don't have a running copy any more AFAIK so it's hard 
to take a look at it.


For one thing instead of showing author and changeset (or version in 
CVS) for every line, it grouped subsequent lines changed at once 
together and showed that information only once for them.
For the other, when you moved your mouse over that author/changeset 
"blame" info, it didn't just show a tooltip but a full-fledged HTML box 
where e.g. bug numbers in the checkin comments could be linked and you 
could call up that link (in a new tab probably) right away and directly 
go to read the bug that changed this code.


Those two features would be great to see in hg blame/annotate as well.

KaiRo

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Axel Hecht]

On 12/11/15 10:46 PM, Joshua Cranmer  wrote:

On 12/11/2015 5:17 PM, Gregory Szorc wrote:

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or
let
me know by replying to this message. Your feedback will be used to drive
what improvements Mercurial makes.


A "reverse blame" feature that shows when a line in an old revision was
deleted or changed in a newer revision is something I've desperately
wanted.


I just recently successfully used `hg grep --all` for that.

Axel


(Relatedly, I know a lot of you want a Mercurial repo with CVS history to
facilitate archeology. I hope to have that formally established in Q1.
Stay
tuned.)


Are you planning on letting comm-central attach to the CVS history as well?



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Boris Zbarsky]

On 12/11/15 6:17 PM, Gregory Szorc wrote:

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan


I went to add stuff, and it was all already there.  ;)


(Relatedly, I know a lot of you want a Mercurial repo with CVS history to
facilitate archeology. I hope to have that formally established in Q1. Stay
tuned.)


You rock.

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Improving blame in Mercurial

[Gregory Szorc]

As Mitchell announced the other night, Mercurial is being awarded a MOSS
grant to improve its blame/annotate functionality. Blame has been cited by
a number of Mozillians as something that they would love to see improved
and the MOSS grant provides the Mercurial Project the means to make it
happen.

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let
me know by replying to this message. Your feedback will be used to drive
what improvements Mercurial makes.

(Relatedly, I know a lot of you want a Mercurial repo with CVS history to
facilitate archeology. I hope to have that formally established in Q1. Stay
tuned.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Xidorn Quan]

On Fri, Dec 11, 2015 at 6:17 PM, Gregory Szorc  wrote:
> If you have ideas for making the blame/annotate functionality better, please
> capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let me know
> by replying to this message. Your feedback will be used to drive what
> improvements Mercurial makes.

I wonder whether it is possible to make blame run in parallel to make
it even faster? Potential method like, split the whole history into X
slices, then do blame independently on each slice, then merge the
result. (As it seems to be a computation intensive task, GIL could be
a real issue, while spawn new processes may not be worth on Windows.)

(I also wonder whether it is possible to make rebase run in parallel,
because I have a nontrivial local tree contains WIP patches (even old
ones I'm not currently working on), and I rebase all of them almost
everyday which always takes some time. However, I guess it is probably
infeasible because rebase mutates the working directory. I probably
should just shelve them, although keep rebasing them may make it
easier to track related changes.)

In addition, I think it would be good to add a command line parameter
on blame to continue previous blame on the ancestor of specified rev.
It isn't always that useful, because you can always just press up
arrow and add/change "-r". But it could be extremely useful if it
correctly handles moved files, since otherwise you would need to
manually input the original path to continue. (Hopefully the "hgweb
links to ancestor's blame" covers this case as well.)

I'm not quite sure what does "Keyboard shortcuts on hgweb" section
mean. It doesn't seem to me adding shortcuts to the blame page makes
sense. But it does make sense to make the file browsing page work like
local file managers or command line path autocompletion when pressing
letter keys. If it is what this section means, I guess it could
probably be described more clearly.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving blame in Mercurial

[Joshua Cranmer ]

On 12/11/2015 5:17 PM, Gregory Szorc wrote:

If you have ideas for making the blame/annotate functionality better,
please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let
me know by replying to this message. Your feedback will be used to drive
what improvements Mercurial makes.


A "reverse blame" feature that shows when a line in an old revision was 
deleted or changed in a newer revision is something I've desperately wanted.

(Relatedly, I know a lot of you want a Mercurial repo with CVS history to
facilitate archeology. I hope to have that formally established in Q1. Stay
tuned.)


Are you planning on letting comm-central attach to the CVS history as well?

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform