Unfortunately, the graphs are too long and complicated for some more 
serious eyeballing, but important point should be _there are_ graphs, 
meaning both "branchA" and "branchB" contain commit 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc... but that we already knew, I`m 
afraid.

So, it does seem like both these commands` output is unexpected:

(*1*) $ git log --format=%H --sparse --full-history branchA..branchB | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
(*2*) $ git log --left-right branchA...branchB | grep 
9ba8f06829b2d2170f23254ed3fe8f3727fe56dc

... where they both find the commit in question, case (2) showing it as 
belonging to "branchB". At least these two seem to be in some agreement 
between themselves :P

I`m getting out of ideas :/ You could try adding "-m" parameter to the mix 
(if that makes any sense), or removing "--sparse", and seeing if anything 
different comes up. Ideally, it would be good to get a (much) shorter 
history with the same behavior which could be examined more easily, but 
yeah...

I`m talking from the top of my head, but maybe a script which will walk 
"branchA" history and do "two dot" range specification with each commit in 
"branchB" history, searching for cases which yield commits which still 
appear in both "branchA" and "branchB" history (so something fishy is 
happening with "log" function, like with sample commit 9ba8f06829 above), 
and finally checking the distance of these "false positive" commits  from 
"branchA" and "branchB" commits used inside "two dot" range specification.

The shorter the distance, the better the commit candidates are for 
examination.

Or/and, you could try bringing this question up on the main *Git mailing 
list* <g...@vger.kernel.org>[1], might be it`s something obvious for people 
much more involved with Git internals :)

[1] g...@vger.kernel.org

Regards,
Buga

On Wednesday, August 9, 2017 at 12:48:28 AM UTC+2, Chris Murphy wrote:
>
> Here it is:
>
> https://gist.github.com/cmurphycode/6a134f8d383d08b024be6c17dda23891
>
> https://gist.github.com/cmurphycode/31a6bd4eafaa9f6e32f7fa465a27ec6d
>
> On Tuesday, August 8, 2017 at 5:50:40 PM UTC-4, Igor Djordjevic wrote:
>>
>> Hmm... For what it`s worth, another two to try out (note addition of 
>> "--ancestry-path"):
>>
>> (*1*) git log --graph --format=%h --sparse --full-history 
>> --ancestry-path 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc..branchA
>>
>> (*2*) git log --graph --format=%h --sparse --full-history 
>> --ancestry-path 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc..branchB
>>
>> Hopefully, these two can show a bit simpler graphs of how 
>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc eventually gets in both "branchA" 
>> and "branchB".
>>
>> On Tuesday, August 8, 2017 at 10:12:21 PM UTC+2, Chris Murphy wrote:
>>>
>>> Definitely:
>>>
>>> - branches made from branchA which are merged into branchA
>>> - branchA has been merged into branchB at least once
>>>
>>> and probably:
>>> branches made from branchA which are merged into branchB
>>>
>>> Here's the result of the commands - doesn't seem like they affected the 
>>> doubledot result:
>>>
>>>
>>> ± % git log --format=%H --sparse --full-history branchA..branchB | grep 
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>
>>> ± % git log --format=%H --sparse --full-history branchA | grep 
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>
>>> ± % git log --format=%H --sparse --full-history branchB | grep 
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>
>>> ± % shasum <(git log --format=%H branchA..branchB) <(git log --format=%H 
>>> --sparse --full-history branchA..branchB)
>>> 5491c7ae2b37eaa77609ac99ecb777f435ed20f9  /dev/fd/11
>>> 5491c7ae2b37eaa77609ac99ecb777f435ed20f9  /dev/fd/12
>>>
>>>
>>> I did some long-shot exploring as well. I thought it might be 
>>> interesting to try to narrow down when this problem "happened". 
>>>
>>> ± % git log branchA --oneline | head -1100 | while read id junk; do git 
>>> log $id..branchB | grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc || echo 
>>> $id; done | grep -v commit
>>> d257212899
>>> 07c8974cbf
>>> 8c9dac3f13
>>> 190772b842
>>> 33ae1d39bd
>>> 4ff39884f6
>>> 283e0c6056
>>>
>>> Essentially, if you walk down the git log for branchA, you get all 
>>> "false positives" until d257212899 which is "correct". (And after 
>>> 283e0c6056, the next several hundred are correct as well)
>>>
>>> That makes 1a6035b06eebbeed6ce2ea4bf3058360f261f8fa the "last" 
>>> (according to git log order) false positive. 
>>> Was hoping that closer look at that commit will help, but haven't found 
>>> anything yet.
>>>
>>>
>>> On Tuesday, August 8, 2017 at 3:54:16 PM UTC-4, Igor Djordjevic wrote:
>>>>
>>>> On Tuesday, August 8, 2017 at 2:38:09 PM UTC+2, Chris Murphy wrote:
>>>>>
>>>>> You're right, I didn't mean to leave the --tags=1 in. I double checked 
>>>>> that the --tags and greps didn't remove any lines from the output.
>>>>>
>>>>> However, I did overlook the carat syntax - on zsh, those need to be 
>>>>> escaped. I repeated this with escapes and also double-checked against 
>>>>> bash 
>>>>> just in case. I think this is what you wanted:
>>>>>
>>>>> https://gist.github.com/cmurphycode/5df15669ce1e5c33f3e69d997b465d6d
>>>>>
>>>>
>>>> This one looks interesting, as we can see both 03dd551f03 (merge base) 
>>>> and 9ba8f06829 (your initial "surprising" commit) in there. By the looks 
>>>> of 
>>>> that graph only, it seems clear that 9ba8f06829 does not belong to 
>>>> "branchA" (its graph ending with merge base commit) -- but, that may be 
>>>> true considering "branchA", "branchB" and the merge base commit 
>>>> 03dd551f03 _only_.
>>>>
>>>> Do you have other branches in your repository, where some of them 
>>>> are/were merged to/with these two branches we`re looking at? If so, that 
>>>> might explain the situation further.
>>>>
>>>> But even if not, I`m thinking if Git`s *"history simplification"* 
>>>> <https://git-scm.com/docs/git-log#_history_simplification>[1] could be 
>>>> the the culprit here...? Could you try your initial commands again, but 
>>>> adding "--sparse" and "--full-history" to them as well? I`m not sure if 
>>>> there are any other "do not simplify history" switches.
>>>>
>>>> So if you could try running something like this (note %h changed to %H 
>>>> as well):
>>>>
>>>> (*1*) $ git log --format=%H --sparse --full-history branchA..branchB | 
>>>> grep 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>>
>>>> (*2*) $ git log --format=%H --sparse --full-history branchA | grep 
>>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>>
>>>> (*3*) $ git log --format=%H --sparse --full-history branchB | grep 
>>>> 9ba8f06829b2d2170f23254ed3fe8f3727fe56dc
>>>>
>>>>
>>>> https://gist.github.com/cmurphycode/114c869323d6d161fd77aa924e769bcd
>>>>>
>>>>> Here's what the branches point to as of right now, just to be sure :)
>>>>>
>>>>> ± % git show-ref branchA
>>>>> c7770ea9a062d189dc2e3238bdd6f5987d86e1cb refs/heads/branchA
>>>>>
>>>>> ± % git show-ref branchB
>>>>> 944405f8308c77200f7f4cb860a3f95a7a8ba6dd refs/heads/branchB
>>>>>
>>>>> Thanks for your patience, I appreciate the help!
>>>>>
>>>>
>>>> No problem, I`m not sure how much helpful I`ll prove to be in the end, 
>>>> but I do find the case interesting, learning something new myself :)
>>>>
>>>> [1] https://git-scm.com/docs/git-log#_history_simplification
>>>>
>>>> Regards,
>>>> Buga
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to