131–133 of 133 posts
Earlier quoted context omitted.
The convention is that a leading `-` isn't recognized as a flag after `--`.
Yes, doesn't that match git's behavior? Or are you saying that's not the case?
Earlier quoted context omitted.
Yes, doesn't that match git's behavior? Or are you saying that's not the case?
Why would `--end-of-options` be needed if `--` always signals the end of options? Please read the article.
> But that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions.
In git, `--` specifies where the options end and the files begin, just as it does for `rm` and other unix conventions. Just exactly as you said, `-` is not recognized as an option after `--`.
So git is following the Unix convention, both as you have described the convention, and as I understand the convention.
Earlier quoted context omitted.
Yes, doesn't that match git's behavior? Or are you saying that's not the case?
Why would `--end-of-options` be needed if `--` always signals the end of options? Please read the article.
and to instead just repeat the claim that git is following the UNIX convention when it clearly does not, as their own quotes says: "that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions."
i.e., `--` is used as a separator, not as a signal that no further leading `-` is significant.