You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
'dirty' added to sys.version on Linux and Mac source builds depending on git version #88591
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2021-06-15.10:27:55.893>labels= ['type-feature', '3.7', 'build']
title="'dirty' added to sys.version on Linux and Mac source builds depending on git version"updated_at=<Date2021-06-16.01:01:50.105>user='https://bugs.python.org/markfinal'
We build Python 3.7 from source in-house for Windows, Linux and macOSX.
It's been noticed that 'dirty' has been appended to sys.version in our builds, even though the source tree has not been modified from a git clone. This only happens for Linux and macOSX.
I traced this to the following commands (which are unchanged in main):
I further traced it to behaviours of different versions of git. In particular, when git is invoked outside of the working tree, and --git-dir is used alone, 'dirty' is always appended.
As far as I can tell, this is still an issue with current versions of git (as of v2.50.1); I can still reproduce it when building outside of the cpython source directory. Looking back at forgotten history, at one time we did use the -C $(srcdir) option but we changed it to using --git-dir because the -C option didn't work with older versions of git. Either we didn't notice at the time or it's been a subsequent change in git that causes the git describe --dirty check to erroneously report the source repo as dirty when using the --git-dir approach but not with -C. See #74596 and #8744 for more info. I have run into this but haven't taken the time to try to track it down so thanks for the reminder!
So what to do about it: I think it should be fixed. The easiest fix would be to revert to using -C again in the hopes that no-one is using very old versions of git. But that's not user friendly. Rather than explicitly check the version number as was suggested in #1679, we could just add a configure test for git -C and, if it fails, revert to using --git-dir.
As far as I can see it was fixed in git 2.21.0 (Feb 2019), RelNotes 2.21.0 (see "git --work-tree=$there --git-dir=$here describe --dirty")
We still need to additionally pass --work-tree.
When we pass --git-dir without --work-tree, git treats the current directory as the working tree. Running the command from a build directory means every tracked file looks deleted, so describe --dirty reports dirty.
Activity
markfinal commentedon Jun 15, 2021
Hi,
We build Python 3.7 from source in-house for Windows, Linux and macOSX.
It's been noticed that 'dirty' has been appended to sys.version in our builds, even though the source tree has not been modified from a git clone. This only happens for Linux and macOSX.
I traced this to the following commands (which are unchanged in main):
https://github.com/python/cpython/blob/main/configure#L2833
https://github.com/python/cpython/blob/main/configure.ac#L50
I further traced it to behaviours of different versions of git. In particular, when git is invoked outside of the working tree, and --git-dir is used alone, 'dirty' is always appended.
It's been noticed in a number of places online, including https://www.reddit.com/r/git/comments/4edtlx/git_describe_in_makefile_always_dirty/
Additionally using --work-tree does avoid the 'dirty' flag for a clean source tree, for git v2.21.0+.
I believe that this was this fix git/git@a1e1900
However, since we do have usage of older versions of git, we've had to go with a different solution, which was to use git -C, i.e.
so that git's working directory is changed to $(srcdir).
The other git commands in the code linked to do not seem to have the same issue, but we haven't changed them.
I'm writing this up in case anyone else has seen the issue, and offer the solution we found if it is useful.
Many thanks,
Mark
StanFromIreland commentedon Aug 11, 2025
This is an upstream issue, and has been fixed for quite a few git versions now, I think this can just be closed.
ned-deily commentedon Aug 11, 2025
As far as I can tell, this is still an issue with current versions of git (as of v2.50.1); I can still reproduce it when building outside of the cpython source directory. Looking back at forgotten history, at one time we did use the
-C $(srcdir)option but we changed it to using--git-dirbecause the-Coption didn't work with older versions ofgit. Either we didn't notice at the time or it's been a subsequent change in git that causes thegit describe --dirtycheck to erroneously report the source repo as dirty when using the--git-dirapproach but not with-C. See #74596 and #8744 for more info. I have run into this but haven't taken the time to try to track it down so thanks for the reminder!So what to do about it: I think it should be fixed. The easiest fix would be to revert to using
-Cagain in the hopes that no-one is using very old versions of git. But that's not user friendly. Rather than explicitly check the version number as was suggested in #1679, we could just add a configure test forgit -Cand, if it fails, revert to using--git-dir.vasiliyk commentedon Sep 22, 2026
As far as I can see it was fixed in git 2.21.0 (Feb 2019), RelNotes 2.21.0 (see "git --work-tree=$there --git-dir=$here describe --dirty")
We still need to additionally pass
--work-tree.When we pass
--git-dirwithout--work-tree, git treats the current directory as the working tree. Running the command from a build directory means every tracked file looks deleted, sodescribe --dirtyreports dirty.Is it old enough to add
--work-treetoGITTAGvariable ofconfigure.acto avoid additional check?