Re: branch --contains / tag --merged inconsistency

["SZEDER Gábor" <szeder.dev@gmail.com>]

Szia Feri,

> I'm moving the IRC discussion here, because this might be a bug report
> in the end.  So, kindly try these steps (103 MB free space required):
> 
> $ git clone https://github.com/ClusterLabs/pacemaker.git && cd pacemaker
> [...]
> $ git branch --contains Pacemaker-0.6.1
> * master
> $ git tag --merged master | fgrep Pacemaker-0.6
> Pacemaker-0.6.0
> Pacemaker-0.6.2
> Pacemaker-0.6.3
> Pacemaker-0.6.4
> Pacemaker-0.6.5
> Pacemaker-0.6.6
> 
> Notice that Pacemaker-0.6.1 is missing from the output.  Kind people on
> IRC didn't find a quick explanation, and we all had to go eventually.
> Is this expected behavior?  Reproduced with git 2.11.0 and 2.17.0.

The commit pointed to by the tag Pacemaker-0.6.1 and its parent have a
serious clock skew, i.e. they are a few months older than their parents:

$ git log --format='%h %ad %cd%d%n    %s' --date=short Pacemaker-0.6.1^..47a8ef4c
47a8ef4ce 2008-02-15 2008-02-15
    Low: TE: Logging - display the op's magic field for unexpected and foreign events
b9cfcd6b4 2007-12-10 2007-12-10 (tag: Pacemaker-0.6.2)
    haresources2cib.py: set default-action-timeout to the default (20s)
52e7793e0 2007-12-10 2007-12-10
    haresources2cib.py: update ra parameters lists
dea277271 2008-02-14 2008-02-14
    Medium: Build: Turn on snmp support in rpm packages (patch from MATSUDA, Daiki)
f418742fe 2008-02-14 2008-02-14
    Low: Build: Update the .spec file with the one used by build service
ccfa716a5 2008-02-14 2008-02-14
    Medium: SNMP: Allow the snmp subagent to be built (patch from MATSUDA, Daiki)
50f0ade2d 2008-02-14 2008-02-14
    Low: Build: Update last release number
90f11667f 2008-02-14 2008-02-14
    Medium: Tools: Make sure the autoconf variables in haresources2cib are expanded
9d2383c46 2008-02-11 2008-02-11 (tag: Pacemaker-0.6.1)
    High: cib: Ensure the archived file hits the disk before returning

(branch|tag|describe|...) (--contains|--merged) use the commit timestamp
information as a heuristic to avoid traversing parts of the history,
which makes these operations, especially on big histories, an order of
magnitude or two faster.  Yeah, commit timestamps can't always be
trusted, but skewed commits are rare, and skewed commits with this much
skew are even rarer.

I'm not sure how (or if it's at all possible) to turn off this
timestamp-based optimisation.

FWIW, much work is being done on a cached commit graph including commit
generation numbers, which will solve this issue both correctly and more
efficiently.  Perhaps it will already be included in the next release.