It wasn't rude to think that this person might not have read the article, when what they write doesn't account for what the article says. What's rude is to not answer the question: "Why would --end-of-options be needed if -- always signals the end of options?"
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.
Please do not rudely assume I have not read the article. Let me show you what the article says:
> 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.