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.
That is probably a very rare case, and any shell-agnostic-completion-protocol could be extensible to handle such a case. But, I think 99% of completions that people want/use on a daily basis could be covered by a machine-readable version of the usual "--help" option (with support for placement of paths, pids, strings, numbers etc.).
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.
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.
Another thing not mentioned in the post, although admittedly more obscure, is that a 2.17.1 client will still happily ferry the evil objects along in its default configuration. I.e. in this sort of setup:
unpatched hosting site ->
in house (patched) v2.17.1 --bare mirror ->
unpatched client
The transfer.fsckObjects setting needs to be explicitly turned on for the in-house mirror so that it doesn't collude in passing the bad objects along from the unpatched hosting site.
The protection in v2.17.1 only gets enabled by default if you're checking out a repository yourself, not if you're merely fetching and re-serving git objects[1].
Turning on receive.fsckObjects as the official v2.17.1 release notes suggest is not sufficient to protect against this attack. It needs to be transfer.fsckObjects, which also turns on fetch.fsckObjects, which is what's needed here.
Thanks, peff, for the feedback. I pushed some changes to try to clarify that this does indeed require `clone --recursive`, and I added a note to credit Etienne Stalsman explicitly. That was an oversight in my haste.
The Git community is great because even though many of the interested parties compete with each other in some form or another, we always put that aside. And that's especially true for security issues.
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".
I think the title you used is a lot less confusing than "A look at the new features in v2.17". A title like that doesn't mention Git would make me think that GitHub is releasing v2.17 if its own product. I don't think there's a way you can clear this up within the title.
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).
This is likely to be said, "`--color=auto` is the default setting, so it's not needed." However, it's good to include it here because some users may have changed their default configuration to disable colors. This way `git log` works as their standard workflow and `git lg` for when they need a bit of color.
