As a tech lead on game projects that feature less than the most technical developers (artists, game designers) the biggest "problem" with git happens to be its strength.
The inconsistent cli and naming can be pasted over with cleaner GUIs. No, the real issue is gits configurability. Not just the configurability but the enforced decentralization of that configurability.
For better or worse, it seems like git is actively hostile to any kind of concept of a central authority. Can I configure hooks for my team? No. Can I configure diff tools for my team? No. Can set recursive pulls to be the default? No. Can I enforce line endings? No. Can I even enforce LFS is setup right? No.
I certainly can't even enforce things in receive hooks and expect team members to know how to change their histories to adhere to our policies.
I love git but its such a pain.
I really wish someone would come up with some kind of "accept remote config" policy or some such thing.
It seems like what you're asking for is a way to configure your coworkers remote computers. Shouldn't you do that with a more general configuration management tool, in the same way you configure any other application for your team? For example, on Windows you could use a custom Default User Profile with .git/config already set up the way you like it.
No, I don't care what computer they are on. I want anyone that pulls my repo to have my hooks etc by default. Even me! Listen, I know there are workarounds, I know there are ways to solve this. My point is they suck.
> I want anyone that pulls my repo to have my hooks etc by default.
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.
Which may be an issue in open-source, but not so much in a captive environment. When I clone an internal repo and run it on local, I myself don't do a security review of it. I trust rest of the people in company to have reviewed the code before committing to main branch. Company has the remote root access on the device it provided and we have internal binaries/scripts regularly used on laptops.
When one executes code from a Makefile, one expects arbitrary code execution. When cloning a repository, or updating a clone of a repository, one does not expect arbitrary code execution. Moreover, one can inspect a Makefile before running code from it, by cloning the repository and looking at the Makefile with a text editor; but one cannot inspect what will be cloned before cloning it (and even if you could, for instance by looking at it through a web interface, there's an obvious TOCTOU risk).
I think what's often overlooked is that git wasn't created as a general solution to version control, but for the specific needs of Linux kernel development.
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).
> git wasn't created as a general solution to version control, but for the specific needs of Linux kernel 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.
Specifically the thing that Git was meant for was there being multiple authoritative roots. In the sense that RedHat can keep their own kernel line and just bring in patches from Linus and other maintainers as well. Everyone can be authoritative! This is great for example if you need to fork a library to make some changes (eg replace a library it's using in it's implementation) but want to keep current with it's improvements.
...this is not the case for most projects. They want to have a clear source of truth for the code.
I'm not sure that is overlooked. It is just not especially relevant for a modern world where the huge majority of versioned development at centralized organizations is done with git.
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's not a criticism really, just an observation ;)
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).
> It just happens so that most software development is more like the Linux kernel and less like game development
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.)
>Git doesn't and cannot accept executable hooks/LFS helpers/etc.
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.
Sure, then you have option 3: Put a "setup-git.sh" script in your repo, and have the README tell users to run that to set things up. If your users are willing to run code from your repo, you can just have them run code from your repo.
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.)
> Sure, then you have option 3: Put a "setup-git.sh" script in your repo, and have the README tell users to run that to set things up.
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.
This is a lot to address but please consider all of the facts.
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.
This line of thinking is low effort and pointless. There's no hate here (in fact, I said love). Tools are meant to be helpful and talking about how to improve them is always good.
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.
> 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.
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.
> Have you managed a large inexperienced team with an offshore component?
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.
If you provide a script for setting up their user environment then that can easily be added. I've done so with Chocolatey and PowerShell (because it's available on all OSes).
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.
Yep. There are reasons Perforce is so prevalent in game development, even if we gripe about it:
- 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.
Git LFS is really robust these days. Personally I think its faster then Perforce now. Reconciles can hang and there's just so much more that can be done in git without hitting the network.
I like that a changelist is one atomic unit in time across everything. Don't underestimate the number of footshoots this avoids. and you can build your tooling on top of it.
Its still pretty fragile but it does work. I wouldn't recommend it for daily usage though. Too many things in p4 show up as impossible breaking changes to the git repo.
Really not defending perforce, but "branches" are not how you usually work, a branch is basically a fork of the repo, it's almost impossible to reconcile.
"Branches", the way we use them in git are more like perforce Shelved CLs.
It's worth pointing out that shelved changes don't have any history though, so cross your fingers to make sure you don't accidentally delete/overwrite something.
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.
Yes, I remember using "shelves" a lot. The branch was created for a major refactor of the code base, and the team I was on moved to that branch. Not sure what happened to it. I hated that company and left after a few months.
I wonder if it’s a workplace I worked at. We ended up having a bunch of generic branch names (one org had colors, another had star-related things), and when a project was done, they just used that branch for something else.
I'm sure that using commercial source control software doesn't HAVE to suck, per se, but the kind of companies that can afford Perforce are usually so bloated and political that you can't avoid that kind of bureaucracy.
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.
Why is that git's responsibility? I've always solved that by making an install script for my team. It installs the our "version control system" (which might be git). It also installs it in such a way that it gets auto-updated. Can push a new config and everyone gets it.
> I really wish someone would come up with some kind of "accept remote config" policy or some such thing.
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.
Git isn’t chosen on its own merits - it’s what the other tools support. If CI servers, issue managers, container tools etc all had a nice VCS-agnostic interface that would be great. But they don’t. We’re stuck with git or at least something that speaks git. Choosing an objectively “better” VCS is often directly coupled to the loss of some other tool.
What works really well for me is using the pre-commit framework (https://pre-commit.com/). This offers an easy way for everybody to run defined hooks locally before committing or pushing changes. That allows people to solve problems before pushing code, but if they don't, they'll get punished by CI, as the same hooks run there as well.
The inconsistent cli and naming can be pasted over with cleaner GUIs. No, the real issue is gits configurability. Not just the configurability but the enforced decentralization of that configurability.
For better or worse, it seems like git is actively hostile to any kind of concept of a central authority. Can I configure hooks for my team? No. Can I configure diff tools for my team? No. Can set recursive pulls to be the default? No. Can I enforce line endings? No. Can I even enforce LFS is setup right? No.
I certainly can't even enforce things in receive hooks and expect team members to know how to change their histories to adhere to our policies.
I love git but its such a pain.
I really wish someone would come up with some kind of "accept remote config" policy or some such thing.