Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> rev-parse does a couple more things, of course, but why doesn't it use
> setup_revision() ? I just wanted to ask before trying to restructure
> things....
Because rev-parse was written as a helper for scripts that take revision
options and non-revision options, whose purpose was to sift the arguments
into four bins:
- revision parameters (e.g. HEAD, master~20)
- revision flags (e.g. --all, --parents)
- non-revision parameters (e.g. Makefile, hello.c)
- non-revision flags (e.g. --stat, -p)
as its primary customer was things like whatchanged that used to be
scripted this way:
git rev-list rev-flags rev-params |
git diff-tree --stdin non-rev-flags non-rev-params |
less
If you call setup_revisions(), it will call handle_revision_opt() which in
turn will call diff_opt_parse(), so I suspect you wouldn't be able to sift
between rev-flags and non-rev-flags.
I think one sane thing to do is to stop adding new rev-flags revision.c
supports to rev-parse (it already lags behind and nobody complained that
rev-parse doesn't understand --first-parent as a rev-flag), and keep its
use as "revision and non revision option sifter" only to support older
scripts written back in v1.0.0 days. Its primary use these days is "turn
symbolic object names into 40-letter SHA-1", but "option sifter" aspect of
the command seems to have outlived its usefulness.
--
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