14 ms·

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

by jayd16 6y ago

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.

dgfitz 6y ago
Someone can correct me if I’m wrong but I think mercurial would solve the issues you describe.
- alkonaut 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - throwawayboise 6y ago
    https://github.com/felipec/git/wiki/git-remote-hg https://github.com/felipec/git/wiki/git-remote-hg
satya71 6y ago
What you’re looking for is called Perforce.
- dijit 6y ago
  Perforce for assets? Sure. 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.
  - andromeduck 6y ago
    It's not p4 but Google3 + Hg CLI was way more fluent than I expected. I wish the third party portion were available as a service outside.
    - dijit 6y ago
      Well, piper is "perforce that doesn't suck (and costs a heck of a lot less)" I wish it were public.
- secondcoming 6y ago
  Last time I used Perforce was around ~2006 in a mobile OS company of approx 3000 devs. Boy was that thing slow. Still though, P4Merge is my go-to diffing tool.
- icedchai 6y ago
  I worked at a company that used Perforce. It took 2 weeks to get a branch created. No thank you.
  - dijit 6y ago
    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.
geofft 6y ago
There are two ways to solve this: 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 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 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.)
- jayd16 6y ago
  >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.
  - geofft 6y ago
    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.)
deleted 6y ago
[deleted]
nightpool 6y ago
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.
- jayd16 6y ago
  Sure there are other solutions. You can kick the can to something else. I still think git should have a solution for a consistent default configuration if features are going to be supported as opt in configurations.
- yCombLinks 6y ago
  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.
  - cesarb 6y ago
    > 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.
    - jayd16 6y ago
      It doesn't need to be without user approval. I would be more than happy to email out a trustable commit hash or what have you.
      - chrisandchris 6y ago
        Having an option to opt-out of some enforcement is somehow not much better than no enforcement at all.
ralph84 6y ago
Enterprise Config for Git might help: https://github.com/Autodesk/enterprise-config-for-git https://github.com/Autodesk/enterprise-config-for-git
deleted 6y ago
[deleted]
billsix 6y ago
Regarding hooks, you can put hooks into the repo https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/ 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.
- Pet_Ant 6y ago
  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).
joshuaavalon 6y ago
If you want central authority, isn't it the job of CI? Use CI to verify the commits fits the styles and review the commits before merging.
- jayd16 6y ago
  CI can punish but it can't solve the problem.
  - Dunedan 6y ago
    What works really well for me is using the pre-commit framework (https://pre-commit.com/ 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.
- rualca 6y ago
  > If you want central authority, isn't it the job of CI? You can't fault a tool for not providing a centralized authority when it's very central design principle is being decentralized.
gfxgirl 6y ago
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.
bigbob2 6y ago
> Can I enforce line endings? .gitattributes text setting
- jayd16 6y ago
  Aha cool. I thought this was a slightly different setting than whats in the config but it looks like the naming is just inconsistent. That's one down. Thank you very much.
junon 6y ago
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. Really tired of the "git hate".
- Pet_Ant 6y ago
  > 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.
  - junon 6y ago
    > 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. They swear by git still though. It works fine.
- UncleMeat 6y ago
  > Not everyone has a GUI system (window system). 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.
deleted 6y ago
[deleted]
etripe 6y ago
> 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. I agree, it is a bit of a pain.
flohofwoe 6y ago
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).
- Pet_Ant 6y ago
  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.
- UncleMeat 6y ago
  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.
  - flohofwoe 6y ago
    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/ https://www.plasticscm.com/ (quite recently acquired by Unity).

by jayd16 6y ago

dgfitz 6y ago

Someone can correct me if I’m wrong but I think mercurial would solve the issues you describe.

alkonaut 6y ago
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.
- deleted 6y ago
  [deleted]
- throwawayboise 6y ago
  https://github.com/felipec/git/wiki/git-remote-hg https://github.com/felipec/git/wiki/git-remote-hg

satya71 6y ago

What you’re looking for is called Perforce.

dijit 6y ago
Perforce for assets? Sure. 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.
- andromeduck 6y ago
  It's not p4 but Google3 + Hg CLI was way more fluent than I expected. I wish the third party portion were available as a service outside.
  - dijit 6y ago
    Well, piper is "perforce that doesn't suck (and costs a heck of a lot less)" I wish it were public.
secondcoming 6y ago
Last time I used Perforce was around ~2006 in a mobile OS company of approx 3000 devs. Boy was that thing slow. Still though, P4Merge is my go-to diffing tool.
icedchai 6y ago
I worked at a company that used Perforce. It took 2 weeks to get a branch created. No thank you.
- dijit 6y ago
  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.

geofft 6y ago

There are two ways to solve this: 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 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 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.)

jayd16 6y ago
>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.
- geofft 6y ago
  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.)

deleted 6y ago

[deleted]

nightpool 6y ago

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.

jayd16 6y ago
Sure there are other solutions. You can kick the can to something else. I still think git should have a solution for a consistent default configuration if features are going to be supported as opt in configurations.
yCombLinks 6y ago
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.
- cesarb 6y ago
  > 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.
  - jayd16 6y ago
    It doesn't need to be without user approval. I would be more than happy to email out a trustable commit hash or what have you.
    - chrisandchris 6y ago
      Having an option to opt-out of some enforcement is somehow not much better than no enforcement at all.

ralph84 6y ago

Enterprise Config for Git might help: https://github.com/Autodesk/enterprise-config-for-git https://github.com/Autodesk/enterprise-config-for-git

deleted 6y ago

[deleted]

billsix 6y ago

Regarding hooks, you can put hooks into the repo https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/ 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.

Pet_Ant 6y ago
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).

joshuaavalon 6y ago

If you want central authority, isn't it the job of CI? Use CI to verify the commits fits the styles and review the commits before merging.

jayd16 6y ago
CI can punish but it can't solve the problem.
- Dunedan 6y ago
  What works really well for me is using the pre-commit framework (https://pre-commit.com/ 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.
rualca 6y ago
> If you want central authority, isn't it the job of CI? You can't fault a tool for not providing a centralized authority when it's very central design principle is being decentralized.

gfxgirl 6y ago

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.

bigbob2 6y ago

> Can I enforce line endings? .gitattributes text setting

jayd16 6y ago
Aha cool. I thought this was a slightly different setting than whats in the config but it looks like the naming is just inconsistent. That's one down. Thank you very much.

junon 6y ago

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. Really tired of the "git hate".

Pet_Ant 6y ago
> 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.
- junon 6y ago
  > 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. They swear by git still though. It works fine.
UncleMeat 6y ago
> Not everyone has a GUI system (window system). 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.

deleted 6y ago

[deleted]

etripe 6y ago

> 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. I agree, it is a bit of a pain.

flohofwoe 6y ago

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

Pet_Ant 6y ago
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.
UncleMeat 6y ago
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.
- flohofwoe 6y ago
  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/ https://www.plasticscm.com/ (quite recently acquired by Unity).