On Wed, Jul 26, 2017 at 4:29 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> When using git-blame lots of lines contain redundant information, for >> example in hunks that consist of multiple lines, the metadata (commit name, >> author) are repeated. A reader may not be interested in those, so darken >> (commit, author) information that is the same as in the previous line. >> >> Choose a different approach for dates and imitate a 'temperature cool down' >> for the dates. Compute the time range of all involved blamed commits >> and then color >> * lines of old commits dark (aged 0-50% in that time range) >> * lines of medium age normal (50-80%) >> * lines of new age red (80-95%) >> * lines just introduced bright yellow (95-100%) >> >> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> >> --- >> >> I played around with it a bit more, using a different color scheme >> for dates, http://i.imgur.com/redhaLi.png > > I do agree with what this one tries to do, in that a block of lines > tend to share the same metainfo as they come from the same commit > and it is distracting to see them repeatedly---doing something to > make their "these are in one group" nature stand out will give us a > much better presentation. Well, we could also try a "zebra" as in sb/diff-color-move to show blocks with the same fancy border detection. > But does this particular implementation work well for people who use > black in on white background? "Darken to make it less distracting" > may not work on both white-on-black and black-on-white users. correct. Once we have a shared understanding what the "interesting things" are and how to handle them, I would add color.blame.<slot> options to make it configurable. > "Show the background only by replacing the letters with SP for > metainfo that are same as previous line" would work for folks from > either camp, I would imagine. And that should be a single feature, > that can be enabled independently from the age based coloring. True, I had that as the very first step of this experiment, I lost the patch for it, but could redo it for presentation and discussion. My impression was that this would remove _too_ much, e.g. if a commit spans more than one screen, you may not see the first line, but only blank space. > The age coloring is much harder to make it work for folks from both > camps at the same time with the same color selection. Yellow on > white would be terribly unreadable for black-on-white folks, for > example. Configuration is key here, I would think, both in the color space, as well as in the selection space. One could imagine that other people would rather have a defined time span, e.g. hard coding "2 weeks/one quarter/ more than a year" or relate that time span to the project history instead of the file history. > If you make "make it less distracting by blanking them out (not > 'darken them')" feature without the age coloring, that can be usable > immediately by folks from both camps, even if you cannot find a way > to do the age coloring that would satisfy both groups. One group > can just leave the knob off and not use the age coloring, while the > other group can use it and people from both camps will be happier > than the status quo. ok. Thanks, Stefan
