Jean Privat <jean@xxxxxxxxx> writes: > ... > This new behavior could affect existing scripts by producing version > number like v1.0.4-14-g2414721-dirty-dirty. > These scripts could be easily fixed by explicitly using HEAD when calling > `git describe` and works with any version of git. > > Signed-off-by: Jean Privat <jean@xxxxxxxxx> > --- > > Initially, I wanted to add an option `--worktree` that works on HEAD and > appends "-dirty" when the working tree is dirty. After rethink I > realized that users (me included) should prefer to describe the working > tree by default, and only describe HEAD if HEAD was explicitly specified. > > Note that documentation of `git describe` did not mentioned the behavior > of the command when no committish is specified. > However, since it is still a behavior change. If the patch is accepted, > it could target version 1.7. > --- > Documentation/git-describe.txt | 5 ++++- > builtin-describe.c | 18 +++++++++++++++++- > t/t6120-describe.sh | 8 ++++++++ > 3 files changed, 29 insertions(+), 2 deletions(-) > > diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt > index b231dbb..c49ecc8 100644 > --- a/Documentation/git-describe.txt > +++ b/Documentation/git-describe.txt > @@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is > reachable from a commit Here is an indication of a linewrapped and broken patch that discourages me to look further. As to the new _ability_, I think it would make sense to reduce the need for an extra invocation of "is the work tree dirty" and this addition is a welcomed one in that sense. However, as you already are aware of, this will break existing scripts; it should not trigger for them. How about "describe --dirty" and "describe --dirty=-mod" (the latter creates v1.6.5-15-gc274db7-mod"), possibly with a short version of options if this proves to be useful and frequently used from interactive sessions? I personally think this does not deserve to have a short option (as you said in the log message, it is primarily a way to make up a version number string, and give interactive users a sense of where in the history he is. If you want to know if your tree is dirty, depending on the reason _why_ you want to know it and what you want to do with the information after learning your tree is dirty, "status", "diff --stat", "add -i" are more appropriate and useful tools) but you (and others) may bring up use cases that I didn't think of when I wrote the beginning of this sentence ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html