That would be a security vulnerability. Hooks in git are not sandboxed, so you'd have arbitrary code execution in the machine of anyone that pulls your repository. In fact, some of the worst security issues the git project has had were ways of tricking it (usually through case-insensitive or normalizing filesystems) into setting arbitrary hooks.

I still think git should have a solution for a consistent default configuration if features are going to be supported as opt in configurations.

Game development is pretty much on the opposite end of the spectrum, 99.9% of game project data isn't text (maybe not by number of files, but definitely by file size), and game development also traditionally isn't as extremely decentralized as Linux kernel development.

The problem isn't git, but that it has become so popular that it's now the defacto standard version control system, and people expect it to work for scenarios it wasn't created for (at least people who don't know much about the specific workflow requirements of large-scale game development).

This is an instance of a more general problem in all software development: tools are created usually to serve a purpose, but when they become popular they end up being used, not because they're a good fit for the problem, but because they're popular -- everybody knows how to use them. The tradeoff (which may be worth making) is the time to learn a new tool vs. the continual cost of using a tool that's not quite right for what you're doing.

...this is not the case for most projects. They want to have a clear source of truth for the code.

Almost none of these thinkpieces about git are saying that Linus was foolish in his approach or that he should have anticipated git becoming the lingua franca for junior engineers at megacorps. Instead almost all of them are talking about git's failing in modern development and bemoaning the lack of a better option, followed by a bunch of people insisting that git is actually awesome as long as you can reason about graphs.

I think your criticism here is actually implicitly already part of almost every discussion about git in modern times.

It just happens so that most software development is more like the Linux kernel and less like game development, so for most software projects git is a good fit indeed, just not for gamedev. Maybe it's worth looking into how CGI studios are managing their data, I guess they have the same problems to solve as gamedev studios.

There are specialized solutions though, like https://www.plasticscm.com/ (quite recently acquired by Unity).

I don't think that is true. Linux kernel development is truly distributed. It is expected that there are multiple completely deployed branches. Most software development using git does have a single point of ownership and a single release branch. It is done on company machines with managed environments.

1. Write and distribute a wrapper script that sets up the clone in the way you want, with hooks, diff tools, LFS, etc.

If you're talking about diff tools and LFS, you need some way to actually install those components, so presumably it shouldn't be hard to get this wrapper script onto end user machines.

My employer uses this and it works well - we have a special command that creates a new clone and configures it appropriately. Once you have a clone, you can use the git commands as usual. People seem fine with this workflow. (Previously the special command was named something like "git-xyzclone" so you could just run "git xyzclone" instead of "git clone". But as we added a few more build/review/release features, we made a general "xyzdev" command with a few subcommands, of which "clone" is one.)

2. Set up /etc/gitconfig (or ~/.gitconfig) and in particular the init.templateDir setting to customize the settings you need.

Again, presumably you have some way to install things - but if you don't, tell employees to run "curl -O https://corp.example.com/.gitconfig" as part of setup, and then you can bootstrap yourself from there.

Git doesn't and cannot accept executable hooks/LFS helpers/etc. from an arbitrary remote server because then as soon as one of your employees clones something from GitHub they'll get event-stream'd. Your authority to enforce configuration comes from your authority (either technical or social) to get employees to install things on their machines - if you have that authority, then there are multiple ways to accomplish this.

(I suppose Git could have a "core.executeArbitraryCodeFrom=https://git.example.com" setting or something, but if you have the ability to push out that setting to all your users, you have the ability to push the actual settings you want.)

I understand the sentiment but I feel like this is just not true. Its designed to share code you plan to build and run, after all. As you say, it seems like we could solve it with signatures and trust but I doubt we'll ever get there, sadly.

In fact you can set the default branch to contain nothing but those two files, and have the setup script switch to the real branch once it's done with its work.

(And if your users have some other way they expect to run code - make, setup.py, yarn run, whatever - you can use that instead as the entry point.)

This is pretty good advice. If projects expect onboarders to run one-time scripts to install third-party dependencies, the least they can do is to also provide scripts to setup the development environment.

There are hooks for pulling and whatnot. This is a vector for malicious code execution.

Not everyone has a GUI system (window system).

Git _has_ to be able to expose low level commands while still being usable.

Decentralization is a _good thing_ when it comes to git. It is directly one of the goals of open source software, for which Git was built.

You can configure all of these things for your team provided they run an init command at least once. Then set up your system however you like via hooks that automatically run to update their configs as necessary.

Remember, your development process is not my development process. Also, not every system that clones a repository wants to run hooks. Git shouldn't force them to.

You can 100% enforce line endings, please research. You just have to configure it in the unit command as mentioned above.

If your team members are not adhering to your policies, then you're not managing them well. It's not git's problem to do your job for you.

For those of us who use git on a daily basis across a wide range of environments, repositories, usecases and websites, git is a dream to use.

Really tired of the "git hate".

Git has lots of configs that are automatic and shared and that you can locally override yourself such as the ignore and attribute files. Why not more? I have no issue (and in fact prefer) if clients can override the projects configuration but git should support a turnkey workflow, at least for its own features. As it stands, you can't add submodules seamlessly, for example.

Its not about adherence. Workflow as Simon-Says is just a bad workflow. This stuff should take zero cognitive load.

This is true. But the number of devs who work entirely in shell is dwindling as basically everything transitions to IDEs.

> If your team members are not adhering to your policies, then you're not managing them well. It's not git's problem to do your job for you.

I totally disagree. There is a reason why we use linters to enforce style guides. Tooling and automation always helps, even if you have strong engineers who are trying to do the right thing.

You're in a bubble then.

Well it could help you in that, and we know that because other VCSes do. Have you managed a large inexperienced team with an offshore component? You are herding cats and there is never enough time to look at everything.

Yep! The engineers we had worked fine like this with just Git, github issues and slack at the time. I've left the company but I know that slack didn't suit them well so they switched to something else.

They swear by git still though. It works fine.

https://www.viget.com/articles/two-ways-to-share-git-hooks-w...

Granted, each team member must set core.hooksPath in their config.

Hope this helps.

Perforce for code? It tries.. but, no thank you. Even if the client was good (it's really not, and will spin a CPU core when it detects a network hiccup) -- it still has a frustrating workflow paradigm, p4ignore is configured per-client, everything is read-only (leading to ugly context switches unless your editor directly integrates with p4) and the command line is so terrible that I think it was actually a joke that someone ran with.

No, perforce is not what you want, without even going into the "decentralised vs centralised" aspect of it.

I wish it were public.

- Large binary asset support.

- Exclusive locks for binary assets.

- Speed. When configured properly, it's very fast, particularly for large repositories.

- Tooling support. It's nearly ubiquitous in gaming.

I'm working on repositories that are 100+ GB and need to support both programmers and artists. Git just isn't the right tool.

We do use git for backend server-side projects. Having to support two different version control systems is a pain, but, again, it's useful to have the right tool for the job.

GitLFS supports locking too.

"Branches", the way we use them in git are more like perforce Shelved CLs.

Fwiw the only major issue I've had with branching is the fact its a full fat copy of your source which can end up taking up a load of space depending on how large your application is post build and how many binaries you dump into perforce.

They seem to be pushing towards "streams" now, but I've heard they make it easier to create development branches but haven't worked with them to find out.

  p4 branch <name>
  (fill out the mapping)
  p4 integrate -b branch //...

Ironically, what files count for p4ignore isn't even centrally configurable. You can't configure diff tools or merge strategies centrally either.

Because every commit has to hit central, receive hooks are actually useful and you can do big branch remappings in a more seamless way than adding a git submodule.

I forget where line ending configs live.

P4 solves some of these things but not everything and adds its own headaches.

Still though, P4Merge is my go-to diffing tool.

But there is a workaround: centralising the .gitconfig in a repo, then symbolically linking it to your home directory, so it gets updated on every pull. I haven't done the experiment, but you might be able to do the same with your .git/hooks.

If need be, you could even cron a git pull in that repo, or add it to your .bashrc, $profile for PowerShell or schedule a task.

I agree, it is a bit of a pain.

.gitattributes text setting

That's one down. Thank you very much.

Use CI to verify the commits fits the styles and review the commits before merging.

You can't fault a tool for not providing a centralized authority when it's very central design principle is being decentralized.