search

jbweston / miniver

Like Versioneer, but smaller
Creative Commons Zero v1.0 Universal
53 stars 10 forks source link

[BUG] miniver does not detect "dirty" state when all changes are staged #61

Closed jsacrist closed 8 months ago

jsacrist commented 1 year ago

Context

As of the current version (0.7.0), miniver has the following mechanism for detecting a "dirty" state on a tree:

  1. Run in a sub-process: git", "describe", "--long", "--always --first-parent or git", "describe", "--long", "--always (if the first one fails). If both these commands fail, don't go any further see code
  2. Assuming one of the commands in the previous step succeeded, take the plaintext output, sanitize and extract values for 3 fields: release, dev, git (see code)
  3. Figure out the "labels" (such as the "dirty" label) needed to construct a valid PEP440-complient format (see code)

BUG / Explanation

This last step is not properly detecting when a tree is "dirty" in two cases I have observed:

  1. When one ore more files have been modified and all modifications have been staged (i.e. when you're ready to commit changes but haven't yet committed them)
  2. When a completely new file has been added to the tree

This undesired behaviour happens because the current approach uses git diff --quiet which returns a value of 1 when a tracked file in the last commit has been modified

Proposal

A better mechanism would leverage the output of git describe --dirty by looking at the ending of the string (which has the form v0.0.2rc6-1-g409e8dd-dirty) in order to determine if the tree is dirty or not