git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: rev-parse vs. rev-list --no-walk
Date: Sat, 01 May 2010 13:05:00 -0700	[thread overview]
Message-ID: <7v1vdv4ccz.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4BDC7471.9030107@drmicha.warpmail.net> (Michael J. Gruber's message of "Sat\, 01 May 2010 20\:35\:29 +0200")

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.

  reply	other threads:[~2010-05-01 20:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-01 18:35 rev-parse vs. rev-list --no-walk Michael J Gruber
2010-05-01 20:05 ` Junio C Hamano [this message]
2010-05-03 15:22   ` Jay Soffian
2010-05-03 15:50     ` Michael J Gruber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v1vdv4ccz.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).