Re: Strange behavior of git rev-list

From: Jeff King <peff@peff.net>
Date: Sep 7, 2017, 09:47 UTC
Message-ID: <20170907094718.b6kuzp2uhvkmwcso@sigill.intra.peff.net>
In-Reply-To: <CACNsYJ-UeEONZ+mDgg6x5Bi+D3VmS=5eGCYq1gEPHVsMEJGojA@mail.gmail.com>

On Thu, Sep 07, 2017 at 11:20:15AM +0200, Paweł Marczewski wrote:

Show 14 quoted lines

> I have an interesting case. In my repository, there are two commits,
> 'one' and 'two'. 'one' is reachable from 'two' (as evidenced by 'git
> rev-list two | grep $(giv rev-parse one)'). However, the output of
> 'git rev-list two..one' is not empty, as is 'git rev-list ^two one'.
> 
> Here is the repository: https://github.com/pwmarcz/git-wtf/
> 
> It seems that the commit dates influence this behavior, because when I
> edit all the dates to be the same, the output of 'git rev-list
> two..one' is empty. Pruning seemingly irrelevant parents also makes it
> empty.
> 
> I verified the behavior on git versions 2.14.1, 2.11.0, and on the
> 'next' branch (2.14.1.586.g1a2e63c10).

Yes, this is known. The commit dates are used as a proxy for graph height (or generation numbers, if you prefer) so that we avoid having to walk all the way down to a merge base before producing any output. But it can give the wrong answer in the face of clock skew.

We walk back five extra commits more than we need to in order to avoid small runs of skewed commits, but obviously you can have arbitrary-sized runs.

-Peff