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

[Max Kirillov <max@max630.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:
...
> 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