Junio C Hamano <junkio@xxxxxxx> wrote Tue, May 22, 2007: > Jonas Fonseca <fonseca@xxxxxxx> writes: > > > Junio C Hamano <junkio@xxxxxxx> wrote Tue, May 22, 2007: > >> Alex Riesen <raa.lkml@xxxxxxxxx> writes: > >> ... > >> > Why should cherry-pick be different? > >> > >> Good question. FYI > >> > >> $ git rev-list --huh? > >> > >> works equally well ;-) > > > > Because it is different? > > > > $ git revert --why-must-it-be-so-hard-to-learn-git-sometimes > > fatal: Cannot find '--why-must-it-be-so-hard-to-learn-git-sometimes' > > > > Because, contrary to git-rev-list, git-revert/cherry-pick is considered > > part of the porcelain? > > No, I did not notice it until now but you are right. The > command line argument parser for these commands is done somewhat > sloppily, compared to others. > > How about doing something like this instead? FWIW, I like it. Sorry for my quick and dirty patch. > -- >8 -- > Fix command line parameter parser of revert/cherry-pick > > The parser was inconsistently done, [...]in that it did not look at > the last command line parameter to see if it could be an unknown > option, although it was designed to notice unknown options if > they were given in positions the command expects to find them > (i.e. everything except the last parameter, which ought to be > <commit-ish>). This prevented a very natural invocation > > $ git cherry-pick --help > > from issuing the usage help. But --help is handled elsewhere, you meant -h ... -- Jonas Fonseca - 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
