On Thu, Apr 22, 2010 at 03:57:31PM +0200, SZEDER Gábor wrote: > > 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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html