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
As of the current version (0.7.0), miniver has the following mechanism for detecting a "dirty" state on a tree:
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
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)
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:
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)
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
The text was updated successfully, but these errors were encountered:
Context
As of the current version (0.7.0),
miniver
has the following mechanism for detecting a "dirty" state on a tree:git", "describe", "--long", "--always --first-parent
orgit", "describe", "--long", "--always
(if the first one fails). If both these commands fail, don't go any further see coderelease
,dev
,git
(see code)BUG / Explanation
This last step is not properly detecting when a tree is "dirty" in two cases I have observed:
This undesired behaviour happens because the current approach uses
git diff --quiet
which returns a value of1
when a tracked file in the last commit has been modifiedProposal
A better mechanism would leverage the output of
git describe --dirty
by looking at the ending of the string (which has the formv0.0.2rc6-1-g409e8dd-dirty
) in order to determine if the tree is dirty or notThe text was updated successfully, but these errors were encountered: