> Its not easy to set up git config settings for a distributed team. I assume for security reasons a repo can't configure its own settings just from a pull but even still I want that functionality.

Git settings can do a lot, including running arbitrary commands. Having this set up automatically is a massive security issue. Put a script in your repo somewhere and instruct people to run the script after cloning.

> Why do I check in the name of the merge tool used for a file type in the .gitattributes but I can't check in what that name points to?

Because the configuration may be different from machine to machine. For example, one machine might have git-lfs installed in /usr/local/bin, another in $HOME/.nix-profile/bin/git-lfs. Similarly, the actual filters may be set up differently from machine to machine, e.g. one person might use `git lfs install` (to install globally) and another `git lfs install --skip-smudge --local` (to install locally to this repo, configured to skip fetching unknown objects on clone or pull).

> I work with less technical artists and they really don't want to think about git configs at all. They just want to save and push. As far as I know there's no solution to preconfigure a repo to pull submodules or set up custom merge drivers. Best thing I've found is to maintain repo setup scripts but its pretty cumbersome and you have to manually target the tools you want to support.

Skimming config right now, I do see a `submodule.recurse` flag which, if set, causes any command except `clone` that has --recurse-submodules to automatically recurse.

The aforementioned setup script could set this config flag and run `git submodule update --init -recursive` to clone the submodules too in case the user didn't pass --recurse-submodules to `git clone`.

>Because the configuration may be different from machine to machine

This is the crux of the issue. I want something to ensure turn-key configuration in a secure and cross platform way.

Maybe github/gitlab could generate something like an installer script instead of just a clone url.

Do you have a cross-platform package manager?

One such package manager can be npm (if you use Node anyway), it can install and run scripts.

But having to run a setup script once could be massively simpler, though less flexible.

You can add a small script to your project that you tell people to run the first time after cloning. Then with that script you can setup everything you want. Such as symlinks to git hooks also stored in the repo (so that they stay up to date), or set up the merge tool that you want.

Our team had started a practice of "devbox setup" scripts in each repo a few years ago. They're invaluable. Instead of following pages of instructions in various state of decay, running just one script puts you into the ready state in a few seconds. Any questions about why something is not working has only one answer: run the setup script.

Highly recommend this.

I love having idempotent makefile tasks that can do this kind of thing.

And as far as "pages of instructions in various states of decay," couldn't agree more that those aren't a good solution. I usually observe those instructions containing lots of terminal commands. I'd rather have those in an executable format, with commenting if explanation is needed. Then it's (usually, hopefully) pretty obvious where something breaks, instead of rotting instructions nobody can say 100% what is or isn't current.

How do you make sure your makefile tasks are idempotent?

A simple way is to use output files to indicate if a command has been run.

Example:

git-setup.out: touch $@

Drop "done" files indicating a large step is done.

Symlinked hook is nice but its not a clean cross platform solution. We're a Unity shop so we support Windows, Mac and Linux devs (or like to try).

I just can't help but feel like if this is the common pattern, then it should be built into one of these tools in a more consistent way.

Along the same vein, I’d love to be able to configure client-side hooks [1] automatically on clone.

[1]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

Use a configuration management system or simply have a custom clone script that users can curl | sh.

This is the sort of thing that a configuration management system like Ansible does. Consider deploying one to all managed devices.

Git itself is not the right place to have it because of the security issues with it, but if you can run Ansible or something similar then you have root on the system anyway.