On 01/08/18 12:49, Chris Angelico wrote:
On Wed, Aug 1, 2018 at 8:40 PM, Thomas Jollans <t...@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
That's not the big I'm confused about. I (like Jeffrey) would have expected
git log v2.7.4 -- Lib/datetime.py
to show something. But right now I'm not sure that ever shows anything for
deleted files, so there's that.
Thomas
--
https://mail.python.org/mailman/listinfo/python-list
