[PATCH 2 of 2 STABLE] log: copy the way of ancestor traversal to --follow matcher (issue5376)

[Yuya Nishihara]

On Sat, 24 Sep 2016 18:59:45 +0100, Jun Wu wrote:
> A tricky case could be when multiple files are followed, for example:
> 
>   $ hg init repo
>   $ cd repo
>   $ for i in 1 2; do
>   >   echo $i >> a
>   >   hg commit -A a -m $i
>   > done
>   $ hg update 0 -q
>   $ echo 2 >> a
>   $ echo 1 > b
>   $ hg commit -A b -A a -m '2 with b' -q
>   $ hg update 1 -q
>   $ echo 1 > b
>   $ echo 1 > a
>   $ hg commit -A b a -m 'b'
>   $ hg merge 2 -q
>   $ echo 1 > b
>   $ hg commit -m merge
>   $ hg log -G -p -T '{rev}:{node|short} {desc}'        # more patches
>   $ hg log -G -p -T '{rev}:{node|short} {desc}' -f a b # less patches
> 
> At first sight, it seemed wrong to output less patches for the second
> command. But after a second thought, I believe showing less patches is the
> sane and desired behavior.

I'm not sure which is correct, but that's what follow() is currently doing
so is reasonable behavior. repo[4]['b'].ancestors() can't walk both parents
right now.

> - off topic -
> 
> By the way, I just encountered an _adjustlinkrev related perf issue when
> working on fastannotate internally. introrev (_adjustlinkrev) can take up
> seconds (and sadly it just returns ctx.linerev() most of the time). Seconds
> is unacceptable comparing with the annotate logic which only takes tens of
> milliseconds.
> 
> I think a stupid way to make it better is to have a map of {fctxnode:
> [linknode]}. To make the map small, it only stores entries where
> len([linknode]) > 1. The challenge would be how to keep the map up-to-date.

That will reduce some cost of _adjustlinkrev(), but maybe we'll still need to
find which linknode is the ancestor of the annotated revision.