Re: [PATCH 1/2] reflog: make the 'show' subcommand really the default

From: Jeff King <peff@peff.net>
Date: Apr 22, 2010, 14:40 UTC
Message-ID: <20100422144059.GA28923@coredump.intra.peff.net>
In-Reply-To: <20100422135731.GS4440@neumann>

On Thu, Apr 22, 2010 at 03:57:31PM +0200, SZEDER Gábor wrote:

Show 8 quoted lines

> > That being said, we tried this same experiment with "git stash [show]
> > <msg>" and ended up rejecting it. However, the main complaint with that
> > was the failure mode for typos. Typing "git stash sohw" would make a new
> > stash.
> 
> I think you meant "git stash [save] <msg>" here, right?
> 
> http://thread.gmane.org/gmane.comp.version-control.git/63566/focus=63645

Er, yeah, that is what I meant. Sorry, thinko on my part.

Show 20 quoted lines

> > In this case, typing "git reflog exipre" would get you:
> > 
> >   fatal: ambiguous argument 'exipre': unknown revision or path not in
> >   the working tree.
> >   Use '--' to separate paths from revisions
> > 
> > and you would repeat the command with the typo fixed, which is perhaps
> > not as bad. And unlike stash, "show" is really the dominant command (I
> > don't think I have ever manually used 'delete' or 'expire'), so it is
> > more likely to be right than not.
> 
> If I understood Junio correctly, he is concerned about a different
> case.
> 
> With my patch "git reflog foo" would show foo's reflog, assuming there
> is a branch named "foo".  This is what people would expect according
> to the documentation.  However, once we implement the subcommand
> "foo", "git reflog foo" will no longer print foo's reflog but instead
> will perform whatever the subcommand "foo" is supposed to do by
> default, which might be difficult to recover from.

Right, what you quoted from me was not Junio's concern. But I argued against Junio's concern earlier in the mail. Basically, it is a corner case. _If_ we add a new command to "git reflog", and _if_ that command is the same as the name of your ref, you must stop using the short form for that ref, and instead use "git reflog show $ref".

So for things like scripts that don't know what $ref will be, and want to be on the safe side, they should continue to use the explicit "git reflog show $ref" form. But there is no reason that humans typing a command need to be bound by that restriction when it is unlikely to happen (and even if it did, they would recover from it easily).

Personally, I don't care either way whether the documentation is updated to match the behavior of vice versa. But I just don't see what your original patch did as very harmful, and I can see how it would be helpful (on the few occassions when I did use "git reflog show", I first typed it forgetting the "show").

-Peff