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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Oct 16, 2009, 22:37 UTC
Message-ID: <20091016223742.GV10505@spearce.org>
In-Reply-To: <dffdbd190910161452o4ac0b426i7c48649eafa0d53@mail.gmail.com>

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.

...

Show 6 quoted lines

> 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.