GeezerVison is showing github.com — 'dirty' added to sys.version on Linux and Mac source builds depending on git version · Issue #88591 · python/cpython
'dirty' added to sys.version on Linux and Mac source builds depending on git version #88591Description
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'] Activitymarkfinal commented on Jun 15, 2021 MannequinAuthor More actions 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
GITTAG="git --git-dir \$(srcdir)/.git describe --all --always --dirty"
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.
GITTAG="git -C \$(srcdir) describe --all --always --dirty" 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 commented on 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 commented on 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-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. vasiliyk commented on 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-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.
$ git --version
git version 2.54.0 (Apple Git-157)
$ git --git-dir ./cpython/.git describe --all --always --dirty
heads/main-dirty
$ git --work-tree ./cpython/ --git-dir ./cpython/.git describe --all --always --dirty
heads/main vasiliyk commented on Oct 22, 2026 Fixed on main by #159442 (gh-159440, another duplicate report of this bug), backported to 3.15 and 3.14.
Can this be closed as completed?
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|