'dirty' added to sys.version on Linux and Mac source builds depending on git version #88591
Copy link
Copy link
Open
Labels
buildThe build process and cross-buildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
| BPO | 44425 |
|---|---|
| Nosy | @ned-deily |
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 = None
closed_at = None
created_at = <Date 2021-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 = <Date 2021-06-16.01:01:50.105>
user = 'https://bugs.python.org/markfinal'bugs.python.org fields:
activity = <Date 2021-06-16.01:01:50.105>
actor = 'ned.deily'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2021-06-15.10:27:55.893>
creator = 'mark.final'
dependencies = []
files = []
hgrepos = []
issue_num = 44425
keywords = []
message_count = 1.0
messages = ['395866']
nosy_count = 2.0
nosy_names = ['ned.deily', 'mark.final']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue44425'
versions = ['Python 3.7']Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
buildThe build process and cross-buildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
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?