Re: Strange reachability inconsistency (apparently, at least...)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 23, 2015, 06:44 UTC
- Message-ID
- <xmqq1tlhunxs.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CAPc5daW=OeNmPVMVWQvp3rfYzfV7z6c1=26E26y0SaRQH7JooA@mail.gmail.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 12 quoted lines
> On Thu, Feb 19, 2015 at 7:03 AM, <ydirson@free.fr> wrote: >> I have a (fsck-clean) git tree in which for 2 commits A and B: >> >> * "git merge-base --is-ancestor A B" returns 0 >> * "git log B..A" returns a non-empty set of commits >> >> I get this behaviour with 2.3.0 as well as with 2.1.3 and 1.7.12. >> >> Is that a real bug or am I just misinterpreting something ? > > Sounds strange. Is it possible to share the repository (or an > anonymised copy of it)?
Actually it does not sound all that strange.
I suspect that B is indeed a proper descendant of A, but you have commits with screwed-up committer timestamps between these two commits that break the cut-off heuristic used by log and reb-list.
Grab the output from "git rev-list B..A". These are supposed to be ahead of B (i.e. should not be reachable from B). Then look at the output from "git log B" (no lower bound) and see if these commits appear there, perhaps like:
$ git rev-list B..A | sed -e 's/^/^/' >phantoms
$ git log --format='%H %ct' B | grep -C2 -f phantomsHits from the latter "grep" would indicate that what the traversal B..A claimed that are not reachable from B contained some commits that are indeed reachable from B.