mg/rev-parse-option-sifter-deprecation

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 3, 2010, 18:25 UTC
Message-ID: <20100603182513.GA25093@progeny.tock>
In-Reply-To: <4C076A6C.601@drmicha.warpmail.net>

Hi,

Michael J Gruber wrote:

> Junio C Hamano venit, vidit, dixit 03.06.2010 01:36:

Show 6 quoted lines

>> Some people might interpret "Deprecate" too strongly; the intent is that
>> we shouldn't keep piling parsing of new rev-list options to it and
>> discourage the use of "option sifter" in new programs.
>
> So, s/deprecated/discouraged/? Is there an alternative we should suggest
> there for scripts needing to sift their options?

Ah, I was wondering about this, too.

Most git tools use parseopt now, whether they are written in sh or C. When I first read this deprecation, I thought, "Wait --- so rev-parse --parseopt is going away?" So it might make sense to mention rev-parse --parseopt separately in the description section.

As for --revs-only and --no-revs, the problem aiui is that we have no in-tree users for them except git filter-branch. Worse still, they share no code with setup_revisions(). Would it be sensible to change this?

 - teach setup_revisions() to use an option sifter instead of parsing
   options in one pass (probably a bad idea), or

 - give setup_revisions a second identity as an option sifter, or

 - teach filter-branch to do its own sifting of filespec arguments
   from revision arguments, and let rev-parse --revs-only rot

Unfortunately, any one of these changes would take time; so to be realistic, regardless of what else happens, the deprecation notice seems like the right thing to do.

| You can use linkgit:git-rev-list[1] directly or
| +linkgit:git-for-each-ref[1] for scripting.

I do not understand the reference to for-each-ref here.

Thanks, Jonathan