Confused on git commit tree about Lib/datetime.py

[Chris Angelico]

On Wed, Aug 1, 2018 at 8:40 PM, Thomas Jollans <tjol at tjol.eu> wrote:
> On 01/08/18 05:16, Jeffrey Zhang wrote:
>>
>> I found a interesting issue when checking the Lib/datetime.py
>> implementation in python3
>>
>> This patch is introduced by cf86e368ebd17e10f68306ebad314eea31daaa1e [0].
>> But if you
>> check the github page[0], or using git tag --contains, you will find
>> v2.7.x
>> includes this commit too.
>>
>> $ git tag --contains cf86e368ebd17e10f68306ebad314eea31daaa1e
>> 3.2
>> v2.7.10
>> v2.7.10rc1
>> v2.7.11
>> v2.7.11rc1
>> ...
>>
>> whereas, if you check the v2.7.x code base, nothing is found
>>
>> $ git log v2.7.4 -- Lib/datetime.py
>> <nothing here>
>>
>> I guess it maybe a git tool bug, or the commit tree is messed up. Is there
>> any guys could explain this
>> situation?
>>
>> [0]
>>
>> https://github.com/python/cpython/commit/cf86e368ebd17e10f68306ebad314eea31daaa1e
>>
> There are some crazy merges in the repository history, that are easy to see
> with gitk (and not so easy to see with github or the command-line porcelain)
>
> In this case, it appears that d26b658f1433a28b611906c078f47bc804a63dd1, in
> the mercurial days, cherry-picked a patch from the 3.2 branch at
> f8b9dfd9a1a3d611d43e3c3ef8031fed96c8dd25.
>
> I don't know why the git tools don't find this by themselves. I suppose this
> is a quirk of the hg-git transition and the different ways hg and git have
> of doing things.

I'm not sure what you're expecting them to find. They find that the
commit in question is part of the 2.7 branch, so every parent of it is
also part of the 2.7 branch. They are correctly reporting it. The
commit is a bit weird, but the tools are faithfully reporting the
weirdness.

ChrisA