[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1472419498.4265.16.camel@kaarsemaker.net>
Date: Sun, 28 Aug 2016 23:24:58 +0200
From: Dennis Kaarsemaker <dennis@...rsemaker.net>
To: Joe Perches <joe@...ches.com>, Julia Lawall <julia.lawall@...6.fr>,
Alexey Dobriyan <adobriyan@...il.com>,
git <git@...r.kernel.org>
Cc: "Levin, Alexander" <alexander.levin@...izon.com>,
Greg KH <gregkh@...uxfoundation.org>,
Sasha Levin <levinsasha928@...il.com>,
"ksummit-discuss@...ts.linuxfoundation.org"
<ksummit-discuss@...ts.linuxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-discuss] checkkpatch (in)sanity ?
On zo, 2016-08-28 at 12:52 -0700, Joe Perches wrote:
> 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.
Powered by blists - more mailing lists