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

This is the one I remember seeing as a kid:

https://www.reddit.com/r/comicbookcollecting/comments/15vvfj...

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

Sounds neat, but I think your name runs afoul of Git's trademark; see https://git-scm.com/trademark

No, it's not the root cause, though it did exacerbate it. See the comment in https://news.ycombinator.com/item?id=22890633.

The parser problem made it worse, but it was neither necessary nor sufficient for the vulnerability. We are fixing it, but decided to leave it out of the critical release path. See https://lore.kernel.org/git/20200414214304.GA1887601@coredum...

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.

Yes, you're right. Patches welcome. We do our development on a mailing list; see https://git-scm.com/docs/SubmittingPatches for details.

However, if you're more comfortable using GitHub PRs, there's a gateway interface at https://gitgitgadget.github.io/.

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

I'm a GitHub employee and spend most of my time contributing to the Git project.

I've always been very happy about how GitHub supported my participation in the community. Sometimes what I do is directly useful to GitHub, and sometimes it's a matter of keeping the project healthy for everyone. It's always been about contributing, and not trying to control.

Microsoft started contributing to Git about 2 years ago, and in the last six months, we've seen them increase their contributions. From what I've seen they've taken the same approach: give developers the resources and freedom to figure out what the project needs and improve it. I'm excited about some of the performance work they've been doing (e.g., fsmonitor integration, graph optimizations).

So I'm optimistic about this with respect to Git. I think it will mean continued support for the project. And I do feel like Microsoft "gets" open source in a way that most people never would have believed 5 or 10 years ago.

No problem! Thanks for all your work on this.

I should have clarified above, too: there were folks from GitHub, Microsoft, and Google working on the various fixes.

A few important points that aren't mentioned in the post:

- you have to tell git to use submodules for this to trigger (so `clone --recurse-submodules` or a manual `git submodule update --init`)

- credit for discovery goes to Etienne Stalmans, who reported it to GitHub's bug bounty program

- most major hosters should prevent malicious repositories from being pushed up. This is actually where most of the work went. The fix itself was pretty trivial, but detection during push required a lot of refactoring. And involved many projects: I wrote the patches for Git itself, but others worked on libgit2, JGit, and VSTS.

Try the diff-highlight script which can be found at:

https://github.com/git/git/tree/master/contrib/diff-highligh...

Er, sorry, I meant to say "...the new features in Git v2.17".

I think that keeps it clear but without making it overtly look like a release announcement.

Try "Git 2.9 is out!": https://blog.bitbucket.org/2016/06/13/git-2-9/

Thanks for the feedback in this thread (I'm the author). The main goal _is_ to let people know about the new version, and about new features they can use (there are a ton of other new features and a lot of backend speedups and cleanups that I don't bother to highlight, because they're not really actionable by normal users).

I've tried to make the Git vs GitHub distinction clear in the first paragraph without belaboring it, but I agree with the sentiment here that the title muddies things. For future iterations I'll look into something more like "A look at the new features in v2.17".

You should probably avoid `--color`, as it turns on color unconditionally, even if output is going to a file. In older versions of Git the %C color placeholders were unconditional anyway. In modern Git, they respect the normal auto-coloring settings.

You can also drop `--abbrev-commit`, since `%h` abbreviates by default (use `%H` if you want the full hash).

I think they meant to say "might do --decorate by default" (which Git does since v2.13.0).

Git assumes it can keep a small struct in memory for each file in the repository (not the file contents, but a fixed per-file size). This repository just has a very large number of files.

One downside of libraries like libssh is that they don't behave the same way as your regular ssh command. So thing you've configured like host aliases, proxy commands, etc, don't just work out of the box (and in some cases may not even be supported at all).

Exactly. It's an option injection attack. There's no shell involved.

We discussed that, but it wasn't clear that doing so was portable. It works for OpenSSH. It doesn't for PuTTY. We don't know what other implementations people might have as `ssh` on their systems.

Git uses Myers diff, but recently added some heuristics to "shift" the hunks in semantically meaningful ways. See https://github.com/mhagger/diff-slider-tools for the experiments that led to this feature.

It also supports a few other diff algorithms: `--patience` and `--histogram`, but in my experience they produce the same output as Myers in most cases.

I think it's not about re-broadcasting, but about providing the show in a better format. The originals were shot on 35mm film, and then that was "mixed down" with the visual effects to some lower-definition format (maybe SVHS, but I'm just guessing) and the result sent to TV stations to broadcast.

To make a high-definition format (e.g., blu-ray or HD streaming) they'd go back to the original 35mm masters and re-convert them. But then all of the visual effects had to be re-added on top.

There are various articles that mention quality issues with the remastering:

http://trekcore.com/blog/2015/08/netflix-brings-vfx-fixes-to...

http://trekcore.com/blog/2012/11/review-star-trek-the-next-g...