Skip to content

'dirty' added to sys.version on Linux and Mac source builds depending on git version #88591

Open

Description

@markfinal
mannequin
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']

Activity

  1. markfinal commented on Jun 15, 2021

    markfinalmannequin
    MannequinAuthor

    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

  2. added
    buildThe build process and cross-build
    type-featureA feature request or enhancement
    on Jun 15, 2021
  3. transferred this issue fromon Apr 10, 2022
  4. StanFromIreland commented on Aug 11, 2025

    @StanFromIreland
    Member

    This is an upstream issue, and has been fixed for quite a few git versions now, I think this can just be closed.

  5. ned-deily commented on Aug 11, 2025

    @ned-deily
    Member

    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.

  6. added
    type-bugAn unexpected behavior, bug, or error
    and removed
    type-featureA feature request or enhancement
    pendingThe issue will be closed if no feedback is provided
    on Aug 11, 2025
  7. vasiliyk commented on Sep 22, 2026

    @vasiliyk
    Contributor

    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

    Is it old enough to add --work-tree to GITTAG variable of configure.ac to avoid additional check?

    - GITTAG="git --git-dir \$(srcdir)/.git describe --all --always --dirty"
    + GITTAG="git --work-tree \$(srcdir) --git-dir \$(srcdir)/.git describe --all --always --dirty"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions