Jean Privat <jean@xxxxxxxxx> 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. -- 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