Re: rev-parse vs. rev-list --no-walk

From: Junio C Hamano <gitster@pobox.com>
Date: May 1, 2010, 20:05 UTC
Message-ID: <7v1vdv4ccz.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4BDC7471.9030107@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> 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.