Re: [PATCH 0/3] --end-of-options marker

[Jeff King <peff@peff.net>]

On Tue, Aug 06, 2019 at 08:14:59PM +0200, SZEDER Gábor wrote:

> On Tue, Aug 06, 2019 at 01:38:17PM -0400, Jeff King wrote:
> > Nothing about "--" is changed by my series; it will still stop option
> > interpretation in rev-list and in other commands. But as before,
> > rev-list (and other Git commands that use the revision.c parser) use it
> > to separate revisions and pathspecs.  That's unlike how most other
> > programs use "--", but that ship sailed for Git in 2005.
> 
> I'd like to draw attention to the oddball 'git filter-branch' command,
> which uses '--' as a separator between 'filter-branch' and 'rev-list'
> options.  Will it still work with this new option?  I think it will,
> but not sure.

Good question.

Certainly "--" will work as it did before, since the code here only
changes behavior when it sees --end-of-options.

filter-branch doesn't use any of our parseopt infrastructure itself, so
it won't understand the new option itself. I.e., this won't work[1]:

  git filter-branch --end-of-options -this-is-a-branch-name

But since it passes rev-list options as-is, this does successfully pass
the name to rev-list:

  git filter-branch -- --end-of-options -this-is-a-branch-name

However, filter-branch itself seems to do some magic of its own with the
rev-list options, and will try to filter HEAD in that case. So I think
it needs further work to cover all cases correctly.

-Peff

[1] I think the first one there would work if filter-branch actually
    used "rev-parse --parseopt". E.g.:

      git rev-parse --parseopt -- --foo --end-of-options --bar <<-\EOF
      cmd
      --
      foo    an option
      bar    another option
      EOF

    yields:

      set -- --foo -- '--bar'