On 05/31/16 19:45, Eric Blake wrote: > On 05/31/2016 11:01 AM, Laszlo Ersek wrote: > >>>> Grepping git's Documentation/RelNotes/ directory, I find: >>>> - in "1.6.6.txt": the introduction of --dirty >>>> - in "1.7.6.4.txt": an apparently important bugfix for --dirty >>>> >>>> Version 1.7.6.4 of git was tagged on Sep 23 2011. >>>> >>>> Does this information help in deciding if we can use --dirty? >>> >>> 5 years old sounds new enough for my liking :-) >>> >>> I guess we could use --dirty and catch the non-zero exit code and just >>> re-try without --dirty. >> >> But, if we can't use --dirty, I should probably use the plus-sign >> fallback (we need *something* to mark a dirty state). >> >> In which case however, shouldn't we just go with the current patch, >> which doesn't care about --dirty at all? Otherwise, some build hosts >> will append "-dirty", and others will append "+". >> >> IMO we should either require --dirty, or go with the current patch. > > Gnulib's build-aux/git-version-gen script doesn't yet use --dirty, but > may be an inspiration for how to generate the same suffix: > > # Test whether to append the "-dirty" suffix only if the version > # string we're using came from git. I.e., skip the test if it's "UNKNOWN" > # or if it came from .tarball-version. > if test "x$v_from_git" != x; then > # Don't declare a version "dirty" merely because a time stamp has changed. > git update-index --refresh > /dev/null 2>&1 > > dirty=`exec 2>/dev/null;git diff-index --name-only HEAD` || dirty= > case "$dirty" in > '') ;; > *) # Append the suffix only if there isn't one already. > case $v in > *-dirty) ;; > *) v="$v-dirty" ;; > esac ;; > esac > fi >
BTW, my patch has a functionality bug. Consider the case when you change some of the tracked files, then stage all those changes with "git add", then *undo* the changes in the working tree only. In this case, my patch will report "dirty" ("+"), because there will be both staged changes (relative to the HEAD commit) and working tree changes (relative to the index). But that's incorrect -- the working tree actually matches the HEAD commit, so the build qualifies as "clean". On the other hand, git-diff-index will do the right thing, namely: git-diff-index <tree-ish> compares the <tree-ish> and the files on the filesystem. which is exactly right. The index (= the staged changes) are irrelevant for a build; only the working tree matters. (Anyway, this is moot now; I'll happily leave it to Fam! :)) Thanks Laszlo