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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html