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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html