In spite of my tongue-in-cheek statement, I get it.
It's huge in the context of non-programming uses of Git. If some people are just sharing some text documents with Git, then it's a big deal.
This is likely on the rise.
E.g. if you look at a site like Github, there is a lot of non-code content in it. Some people stash that content, and other people believe that content to just be harmless files that will never perpetrate an exploit just from being cloned.
Well, I clone repos to inspect code all the time, and when I run code, it’s usually not with the same permissions as the corresponding `git clone`. Maybe I should be better about sandboxing Git…
1. Download container description (Dockerfile)
2. Upon image build it "compiles things" (e.g. processes/assembles javascript)
3. Build fails, because it pulls architecture incompatible library (or does not pull architecture mandated library)
4. Fix build scripts, rebuild container image
5. Verify container
6. Pull repo
7. Reproduce changes, commit
8. Push
Nothing apart clone-edit-push happens on the repo. The code can be executed on a remote, hardened, isolated system. With proliferation of containers I guess this scenario will become more and more common among ops people.
