Re: Strange reachability inconsistency (apparently, at least...)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> On Thu, Feb 19, 2015 at 7:03 AM,  <ydirson@xxxxxxx> 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 phantoms

Hits 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.

--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]