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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: May 3, 2010, 15:50 UTC
Message-ID: <4BDEF0BB.6080009@drmicha.warpmail.net>
In-Reply-To: <t2z76718491005030822l469c720ag1466ecd2bad31f32@mail.gmail.com>

Jay Soffian venit, vidit, dixit 03.05.2010 17:22:

Show 12 quoted lines

> On Sat, May 1, 2010 at 4:05 PM, Junio C Hamano <gitster@pobox.com> 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