threads / discuss / 43950

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

Subject: Re: [Ksummit-discuss] checkkpatch (in)sanity ?

## tl;dr

4 messages between Aug 28, 2016 and Aug 28, 2016.

replies: 3people: 3as markdown or json

Joe Perches· Aug 28, 2016, 19:52 UTC · lore

On Sun, 2016-08-28 at 11:59 +0200, Julia Lawall wrote:

> On Sun, 28 Aug 2016, Alexey Dobriyan wrote:

[]

Show 7 quoted lines

> > The problem is that c-h.pl generates noise in the commit history and
> > makes git-blame less useful than it can be.
> 
> Could it be that this is a problem with git blame, rather than with
> checkpatch?  Last year there was a discussion on this list about how there
> is an option to git blame that will cause it to step through the history,
> and not show only the most recent patch that has modified a given line.

It is more or less an ease-of-use limitation of git blame.

There are some that want an ncurses only version of git blame that could use arrow-key style navigation for historical commit line-ranges.

git gui blame kind of works, but it's not ncurses/text based. git-cola kind of works too, but it's not text based either.

Are there other existing tools for blame history viewing?

Jiri Kosina· Aug 28, 2016, 20:35 UTC · re: Joe Perches · lore

On Sun, 28 Aug 2016, Joe Perches wrote:

> Are there other existing tools for blame history viewing?

fugitive vim plugin has 'Gblame' command, which I personally find rather useful, and given the text-oriented nature could potentially be useful for your needs.

-- 
Jiri Kosina
SUSE Labs

Dennis Kaarsemaker· Aug 28, 2016, 21:24 UTC · re: Joe Perches · lore

On zo, 2016-08-28 at 12:52 -0700, Joe Perches wrote:

Show 27 quoted lines

> On Sun, 2016-08-28 at 11:59 +0200, Julia Lawall wrote:
> > 
> > On Sun, 28 Aug 2016, Alexey Dobriyan wrote:
> []
> > 
> > > 
> > > The problem is that c-h.pl generates noise in the commit history
> > > and
> > > makes git-blame less useful than it can be.
> > Could it be that this is a problem with git blame, rather than with
> > checkpatch?  Last year there was a discussion on this list about
> > how there
> > is an option to git blame that will cause it to step through the
> > history,
> > and not show only the most recent patch that has modified a given
> > line.
> It is more or less an ease-of-use limitation of git blame.
> 
> There are some that want an ncurses only version of git blame
> that could
> use arrow-key style navigation for historical commit
> line-ranges.
> 
> git gui blame kind of works, but it's not ncurses/text based.
> git-cola kind of works too, but it's not text based either.
> 
> Are there other existing tools for blame history viewing?

tig has a neat way of doing blame history digging: do a `tig blame filename`, select a line and hit the comma key to re-blame from the parent of the commit that was blamed for that line.

(hat tip to Jeff King who pointed out this trick recently)

D.

Joe Perches· Aug 28, 2016, 21:57 UTC · re: Dennis Kaarsemaker · lore

On Sun, 2016-08-28 at 23:24 +0200, Dennis Kaarsemaker wrote:

Show 11 quoted lines

> > There are some that want an ncurses only version of git blame
> > that could use arrow-key style navigation for historical commit
> > line-ranges.
> > 
> > git gui blame kind of works, but it's not ncurses/text based.
> > git-cola kind of works too, but it's not text based either.
> > 
> > Are there other existing tools for blame history viewing?
> tig has a neat way of doing blame history digging: do a `tig blame
> filename`, select a line and hit the comma key to re-blame from the
> parent of the commit that was blamed for that line.

Thanks, of course I neglected to mention tig.

What I think some here want is the ability to view back and forth from old to new rather than just split the window horizontally with the commit content.

Basically, apply the patch hunks for a specific range to see color coded changes rather just show the entire patch in a separate view.

Sure, seeing the commit log and patch is useful.

Seeing the block of code pre and post patch for the specific section can be more useful.