> 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

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