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'
