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.
-- Thomas
--
https://mail.python.org/mailman/listinfo/python-list
