How core Git developers configure Git
18 comments
·February 22, 2025videlov
> excludesfile = ~/.gitignore
It has happened to me in the past to wonder why certain files/folders are ignored by git, only to realise that I had a global git ignore for the particular pattern.
Not sure l’d recommend this as a good default, but perhaps others have better memory than I do.
idle_zealot
It makes sense to have global defaults specific to your machine if and only if your workflow (editor, personal tooling) creates files that you don't want as a part of any project. Things like vim or emacs temp files, macOS's DS Store files, etc. This doesn't apply if your team uses standardized editor configs.
g4zj
This option in general seems odd to me. Wouldn't all contributors to the project need to coordinate their exclusions manually this way? Am I missing something?
tomjakubowski
It's useful for bespoke developer settings. I like to keep a scratch folder in virtually every repo I work on, so I have `/tomscratch` in my global excludes file. Adding this to .gitignore in every repo I work on would just be noise for everyone else.
Vinnl
I imagine it includes things like .DS_STORE.
npteljes
I agree with you. In fact, I think it's better to free up "configuration" memory, and use it to store "best practice" or "process" in general. I find that convention over configuration works out better on a long run, and when switching between projects - either the developer themselves, or when parts of the team leave and others join.
jcalvinowens
Agreed, I don't want my checkout implicitly ignoring a file somebody else's checkout wouldn't.
albingroen
I’d bet my money on the GitButler team. They’re experts in a small market and I think they’ll do something great. I don’t think their current product is it, but I think they’ll do something great.
schacon
Curious what I might have missed that you all put in your `~/.gitconfig`
null
wahnfrieden
.DS_Store
*.swp
infogulch
That's .gitignore. GP is asking about what you have in your .gitconfig.
mattmanser
This was posted already earlier today, lots of comments on the other thread:
MzHN
Might be worth mentioning that fsmonitor is Windows and Mac OS only.
Also I wish GitHub and GitLab had colorMoved.
supernaught
Correct, however it looks like fsmonitor might (someday?) be available on Linux too: https://lore.kernel.org/git/pull.1352.git.git.1665326258.git...
Edit: or go third-party? https://github.com/jgavris/rs-git-fsmonitor I don't have any experience with it though.
wetpaws
[dead]
Good stuff here. But I don‘t like the auto pruning suggestion as a reasonable global default. Or at least this shows that users who really see this as useful see no real difference between git and let’s say SVN. The whole idea is that the system is distributed and that you don‘t follow blind another upstream. But I grant the fact that most projects are not developed like the Linux kernel for which git was created. But there is another issue. I personally like the fact that I keep a history of old branches etc. This can also save me if I or another person in the team deletes a branch by accident. I assume that pruning would maybe not delete the objects right away. Need to check that.
What would actually happen if I have a branch under development and it gets deleted from remote? Will it remove locally for me then? I guess only when my local head is equal to what remote pointed to.