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

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

quoted text
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html