Blame should offer coloring choices about gitblit HOT 12 CLOSED

Hi James,
  I thought I'd have a go at implementing this feature, hopefully I'll be able to implement
what you're looking for. Do you have any specific ideas on how you'd like this implemented,
how the coloured blame should look, etc?

  I've knocked together something just to find my feet for working inside Gitblit and
I've attached a screenshot of my (very) rough attempt. Is it in the ballpark of what
you're looking for or am I way off?

Cheers,
Alex

Nice.  That looks like what I would have done.  Are you assigning color from a fixed
pool? Or trying to calculate one from the author name?  Either way that looks good.

As for working inside Gitblit... the internal architecture is about to change - what
you've learned is transferable.  I've been refactoring for modularization and dependency
injection.  As you can imagine, the change is massive and touches just about every
class.  It still has all the same "powers" - but access to them is slightly different.
 I hope to land the refactor this weekend.

Ok I've done a little bit more work in the Color Mapping part. It now generates random
colors, applies a tint to "lighten" them so they don't dominate the page and remembers
that color given a key (a Map). Therefore subsequent invocations will result in the
same color for a given key. In the example above the key is the author thinking that
when I add the ability to select coloring by commit the key will be the commit ID instead.

When it comes to coloring by Age is a random color ok or would you like shades/tints
of a single colour to indicate age (dark = oldest, light = newest)?

Is having a Map of key-to-color ok or would you prefer me to see if I can "calculate"
a color from a key? I noticed my color mapping util needed to be serializable which
concerned my slightly I don't know where it's actually going, how long it's being stored
for etc. which might have memory implications. I was surprised it was serializing in
the first place but that'll just be me not understanding Wicket yet. 

As for your refactoring that shouldn't cause me any problems, I'll be able to reapply
my changes without too much trouble I'm sure.

One more question... how would you prefer I submit my code for review, once I'm done?
GitHub PR, patchsets in an email, etc?

Any instance or final object in a page must serializable.  This is how Wicket operates
with server-side sessions/pages/etc.  I'm not in love with that so I try to avoid generating
stateful pages but here it might be unavoidable - it might depend on how you want to
trigger the repaint: one option might be to call back to the page with a query parameter
instead of an ajax call.

I think age should be shades of 1 color, otherwise it loses meaning.

A Github PR is my current preference.  When I finish the Tickets feature and hopefully
(someday) have OpenID auth my preference might change to Gitblit-hosted review.  But
that ain't gonna happen in the next few weeks.  :)

Thanks for tackling such an old issue!

I'll keep with what I've got for the moment and revisit it later on with the aim of
making it stateless if possible. 

I've started working on the repaint. I've added links which go back to the BlamePage
with a "blame type" parameter. The location of the links is messy at the moment (in
the same row as the commit|line|data headings) but the alignment is wrong. I'd like
to have the links to the right of that header whilst the "commit|line|data" part stays
far left. I'd also probably like to somehow highlight the currently selected blame
type but I'll get to that later :) Do you have any preferences as to where those links
should appear? If so I'll do that instead.

1 color it is. 

Ok hopefully I'll have something ready fairly soon, spare time permitting. Are there
any deadlines to aim for?

No problem! It's a low-risk piece of work which is proving to be a nice introduction
to the Gitblit source, Wicket, etc. and if my code does make it into Gitblit it'll
be really nice to have contributed a feature. 

End of December.  No hurry.

James, I think I'm in a position to raise a Pull Request for this feature. Shall I go
ahead and raise the PR for you to review it or do you want to take a look at my repo
first?

https://github.com/alexmob/gitblit/tree/issue-2 

I took a peek.  Go ahead, create a PR, and we'll do the review dance.  :)

Done :)

1.4.0 released.