Re: [Feature Request] git blame showing only revisions from git rev-list --first-parent

From: Max Kirillov <max@max630.net>
Date: Oct 18, 2015, 11:38 UTC
Message-ID: <20151018113857.GA5722@wheezy.local>
In-Reply-To: <20150915100538.GA21831@sigill.intra.peff.net>

On Tue, Sep 15, 2015 at 06:05:39AM -0400, Jeff King wrote:

> It seems like nobody is actually that interested in what "blame
> --first-parent --reverse" does in the first place, though, and there's
> no reason for its complexity to hold up vanilla --first-parent. So what
> do you think of:

...

Show 6 quoted lines

> Combining "--reverse" with "--first-parent" is more
> complicated, and will probably involve cooperation from
> revision.c. Since the desired semantics are not even clear,
> let's punt on this for now, but explicitly disallow it to
> avoid confusing users (this is not really a regression,
> since it did something nonsensical before).

Hi.

I might be late for this discussion, but I seem to have a case when blame --reverse --first-parent seems to work.

Consider the folowing history (from left ro right):

       +-----------------D1-+
      +--->C1------>C2-+     \
     /                  \     \
A0->A1-------->A2---..-->A3-->A4-->A5
 \            /
  +->B1-->B2-+

, and a line was removed in B2. Then, blame --reverse returns D1 for this line, which is, while technically correct, absolutely useless to find real place where the line was removed. But blame --reverse --first-parent seems to return A1, which is much more useful and actually what I would expect to return. I tried it recently with 2.3-something and it seems to work as expected.

Was it the behavior you mentioned as nonsensical or you have some other examples?

So please may I ask to not kill this completely. As about the issue mentioned by Junio, it could fail loudly if the requested range is not a first-parent chain.

-- 
Max