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

["Shawn O. Pearce" <spearce@spearce.org>]

Jean Privat <jean@pryen.org> wrote:
> > 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.
...
> 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.

Yup.  That's my take on it too.  This default of "no argument means
describe the working tree" matches with tools like `git diff`,
`git checkout`, `git status`, `git blame` with no revision arguments.

We are being blasted by users for being inconsistent in our UI in too
many places.  Here's yet another.  We need to start standardizing
on a more consistent UI model.  If that model means we need to
use a "--worktree" flag to mean "against the working tree" then
we should start doing that also to `git status`, `git checkout`,
`git blame`, and `git diff`.

>  $ 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 ?

IMHO, that should be a fatal usage error, if we go that approach.
I would also argue `git describe --dirty HEAD` is equally fatal.

-- 
Shawn.