mg/rev-parse-option-sifter-deprecation

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 03.06.2010 01:36:

>> 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