# rev-parse vs. rev-list --no-walk 4 messages from 2010-05-01 to 2010-05-03. Participants: Michael J Gruber, Junio C Hamano, Jay Soffian. Thread: https://gitlist.dev/t/23657 ## Michael J Gruber, 2010-05-01 18:35 Subject: rev-parse vs. rev-list --no-walk Message-ID: <4BDC7471.9030107@drmicha.warpmail.net> URL: https://gitlist.dev/e/4BDC7471.9030107%40drmicha.warpmail.net ``` In connection with an upcoming RFD patch, I noticed that rev-parse and rev-list --no-walk do very similar things (OK - I knew *that* already) in different ways. In particular, rev-list uses the ordinary setup_revision() which is used in many other places, whereas rev-parse does it's own thing. 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.... As it is we have the maintenance burden of keeping both rev option parsers in sync. And, in fact, they are not: - setup_revision() (and thus rev-list) explicitly adds HEAD for "--all", rev-parse does not - setup_revision() outputs each sha1 only once, rev-parse possibly multiple times (in case of coinciding heads/tags...) Of course, rev-parse and rev-list --no-walk do actually very different things, as one can see from the results of "--tags" on both (partially answering my own question here). And that difference is intentional. So: - Should setup_revision() really add HEAD on --all? (Probably yes.) In this case I'd adjust the doc. - Shouldn't rev-parse --all add HEAD as well? - Is there any way to use setup_revision() without resolving tags to commits etc. (and thus using it for rev-parse)? Michael ``` ## Junio C Hamano, 2010-05-01 20:05 Subject: Re: rev-parse vs. rev-list --no-walk Message-ID: <7v1vdv4ccz.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v1vdv4ccz.fsf%40alter.siamese.dyndns.org In-Reply-To: <4BDC7471.9030107@drmicha.warpmail.net> ``` Michael J Gruber 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. ``` ## Jay Soffian, 2010-05-03 15:22 Subject: Re: rev-parse vs. rev-list --no-walk Message-ID: URL: https://gitlist.dev/e/t2z76718491005030822l469c720ag1466ecd2bad31f32%40mail.gmail.com In-Reply-To: <7v1vdv4ccz.fsf@alter.siamese.dyndns.org> ``` On Sat, May 1, 2010 at 4:05 PM, Junio C Hamano wrote: > 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. We tell scripters to be careful to use the plumbing and not the porcelain. From that standpoint, shouldn't we do our best to prevent the plumbing from falling into disrepair? (Or perhaps I'm reading too much into what you say.) j. ``` ## Michael J Gruber, 2010-05-03 15:50 Subject: Re: rev-parse vs. rev-list --no-walk Message-ID: <4BDEF0BB.6080009@drmicha.warpmail.net> URL: https://gitlist.dev/e/4BDEF0BB.6080009%40drmicha.warpmail.net In-Reply-To: ``` Jay Soffian venit, vidit, dixit 03.05.2010 17:22: > On Sat, May 1, 2010 at 4:05 PM, Junio C Hamano wrote: >> 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. > > We tell scripters to be careful to use the plumbing and not the > porcelain. From that standpoint, shouldn't we do our best to prevent > the plumbing from falling into disrepair? According to git(1), git rev-list is low-level, but git rev-parse is not! >From a cursory look at current source it would be simple to discourage use of rev-parse for revision flags (and, probably, as an option sifter). There's no need to remove them (and break some outside scripts). Junio suggested not to add any new ones to rev-parse. That would make my RFD patch (--heads, --locals) smaller, and answers the questions about solving the difference between rev-parse and rev-list "-all" regarding HEAD. But maybe git-rev-parse(1) should change then, in order not to encourage its use as option sifter. Everyone stops by this man page when looking up revision syntax. Michael ```