On the page you linked, you can see that `ctype.h` reserves all prefixes of `is[a-z]` and `to[a-z]`, and `string.h` reserves `str[a-z]`. These come from the C standard (in C99, it's 7.26 "Future Library Directions"), though I don't think they use the word "reserved" there.
> Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.
I suppose it would be a little more convenient if you could ask `git blame` to format the whole line itself, but that wouldn't be part of the `--porcelain` output.
All that said, that pipeline is quite slow on something like linux.git, as it runs a series of blames which will walk over the same history many times. I think:
git log -STODO --format=%ad --date=short
would be much faster (it's not _quite_ the same thing, as it counts TODOs which went away, but is a reasonable variant).
> What do you want `blame --porcelain` to do that it doesn't? Using:
It increases the complexity, due to time conversion. One can certainly solve the general problem by throwing enough awk/perl/sed at it, but an option to customize the blame output would make it significantly more ergonomic (and the oneliner much simpler).
Why not? If you made a backup product called "Windows Backup" (or more relevant to this example, a collaboration product for Microsoft Office called "Office Duck"), Microsoft will definitely go after you for trademark infringement. Why should it be any different for an open source project with a registered trademark?
'In addition, you may not use any of the Marks as a syllable in a new word or as part of a portmanteau (e.g., "Gitalicious", "Gitpedia") used as a mark for a third-party product or service without Conservancy's written permission.'
That was discussed before the fix, but it doesn't matter. The helper protocol specifies a raw newline as the delimiter, and both sides of the conversation parse on that.
I see a lot of comments to the effect of "shouldn't XYZ also be banned". The answer is that we're not necessarily trying to be exhaustive. The point is to flag common errors before we even hit review, so we add new functions mostly when somebody tries to misuse them. I don't recall anybody trying to abuse longjmp() in Git's codebase yet (and no, that's not a challenge).
Peff, for the people asking in the thread, is there a place where correct alternatives are suggested or demonstrated?
I know there are a few different places that talk about how to use git's internal machinery, but not sure if any are specific to these banned functions.
The original commits mentions git's strbuf API[0] and its xsnprintf, a variant of snprintf which asserts that the destination buffer was big enough[1] (rather than just return truncation information).
For other codebases, snprintf is the usual recommendation, and careful straight buffer manipulation (mem*) iff performances are a concern.
The commit messages that add them to banned.h discuss alternatives, though most of the explanations are Git-specific and assume you'll look elsewhere to figure out how to actually use those alternatives.
> the .git/index file, which uses mmap, is synced incorrectly by file sync tools relying on mtime
This part implies that the index file is written via mmap, but that's not true. It is fully rewritten to a new tempfile/lockfile, and then atomically renamed into place.
Git does not ever mmap with anything but PROT_READ, because not all supported platforms can do writes (in particular, the compat fallback just pread()s into a heap buffer).
https://www.reddit.com/r/comicbookcollecting/comments/15vvfj...