Re: [PATCH RFC] git describe without refs distinguishes dirty working tree

[Jean Privat <jean@pryen.org>]

> I still haven't heard anything that helps me to decide which way the
> default should be.  The only concrete thing I have heard against the
> change of the default is that it will break existing setup, but I haven't
> heard anything concrete for the change yet.

As a said in the comment part of the initial message, I initially
planed to add a --worktree option that means "I want you to describe
my working tree". Knowing that from my naive point of view, the
description of the working tree is what build script wanted :
description of HEAD (on which is based the working tree) + saying that
if the working tree is dirty or not (done manually by scripts).
Moreover, in my naive view with the "--worktree" option, no refs where
allowed (i.e. describe the working tree xor describe some commit
references).

Then, I realized that for some other git commands that can work both
on the working tree and on an arbitrary commit reference, the default
was to work on the working tree and require an explicit HEAD to work
on the HEAD commit. Thus it makes sense to me that "git describe"
alone should describe the working tree and that "git describe HEAD"
should describe the HEAD commit.
Moreover, since build scripts use "git describe" not to describe an
arbitrary commit but to describe the working tree, it is nice to make
what thez really want the default.

Currently, the breaking of scripts is the only reason that makes me
not entirely convinced that default should be to describe the working
tree. But I think that if "git describe" could be redesigned,
describing the working tree by default should be the right thing.
I also think that the breakage should not be so important:
* it could be fixed without requiring/checking a specific git version
* it appears only for people that build on a dirty tree
* the effect may be only to produce a strange version number
* git describe is porcelain :)
* 1.7 may break other things, so some fixing me be required anyway :).

If git people prefers that default remains HEAD, I have no real strong
objection (I still have to resend the patch because of line breaking
anyway).

> How about "describe --dirty" and "describe --dirty=-mod" (the latter
> creates v1.6.5-15-gc274db7-mod")

May be better than "--wortree" (especially because of the value part),
but what happen with
 $ git describe --dirty v1.2.1
should it show an error, output "v1.2.1" anyway, or output
"v1.2.1-dirty" if the working tree is different from v1.2.1 ?

-J