peff

If it's used for both, then you couldn't have "--" itself as a pathspec. In your first example, the current meaning is: a pathspec containing "rev", "--", and "pathspec".

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.

What do you want `blame --porcelain` to do that it doesn't? Using:

    git blame --line-porcelain "$1" -L "$2,"$2" |
    perl -MPOSIX=strftime -lne '/^author-time (\d+)/ and print strftime("%Y", localtime($1))'

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).

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.

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.

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).

> 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).

Perl has shipped with a `rename` utility for ages, that you can use like:

    rename 's/foo/bar/' *.ext

Of course you have to know Perl...

This makes sense for some completions (e.g., vanilla lists of options). But often the completion depends on other context that the binary doesn't need to know about. For example, I complete `git grep` patterns based on ctags. There's no reason git should know about ctags; it's only my personal completion that brings the two together.

I'm not sure how I feel about sticking so much complexity into the kernel, but one thing I would really enjoy is being able to use standard tools like `strace` on TLS-speaking processes. With user-space implementations, you only get to see the encrypted content (you can use other tools like ltrace to get around this, but I've found that tools for observing the kernel-userspace boundary are easier to use).