GitButler relicensed[1] to FSL, so it's source-available now, open-source after two years.

[1]: https://blog.gitbutler.com/gitbutler-is-now-fair-source/

My gitignore is just a pile of things I _always_ want to ignore:

     # OS
    .DS_Store

     # Editors
    .vscode-server/
    .idea/

     # Javascript
     .npm/
     node_modules/

     ...more stuff per language

There's also `git status --ignored` to check if you're missing anything.

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.

I have to put a complete one in every project. I work with a lot of junior devs. On many occasions they're committing too much - cause they a) don't have good global config and b) are not selective about git add. A teaching opportunity but annoying to clean up.

Just a view from the other end of the spectrum.

https://git-scm.com/docs/git-check-ignore is useful to diagnose why a file is ignored

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?

Agreed, I don't want my checkout implicitly ignoring a file somebody else's checkout wouldn't.

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.

I disagree. If it's minimalistic and focused on your commonalities across projects in a computer, such as VScode stuff which shouldn't be committed to a general repo, I think it's the right and unobtrusive choice.

I had the same thought, I got an alias set up in my ~/.gitconfig to clean up branches that gets deleted from remote when I'm ready

`gone = !git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D`

Because Git is distributed, there's no "a branch" foo or whatever; that's a very pointedly centralized-logic, non-DVCS way to treat Git. If Alice has a head named "foo", Bob can fetch Alice as a remote and get a remote-tracking head "alice/foo", which has no bearing on any head named "foo" Bob has; it's just a view of Alice's state.

You can see why you'd want to prune these on fetch, if you want your refs/remotes/alice state to mirror Alice's state; this means removing "alice/foo" if "foo" on Alice is removed. You also might not want to, that's fine. But if you use git fetch as though Git were a DVCS, this is exactly the natural behavior; it's only when you imagine Git is centralized that it starts seeming strange.

So the answer to your final question is "this is not how distributed VCSes work".

(Just don't ask about tags. Ugh, what a nightmare! To be fair, the idea is that you don't go around fetching tags.)

This is my global gitconfig (minus personal things like user.email etc):

  [core]
       pager =
  [pull]
       ff = only

  [push]
       default = upstream

  [alias]
       tlog = log --graph --oneline

  [status]
       showStash = true
  [stash]
       showPatch = true

.DS_Store

*.swp

Agreed. If you're using tags for anything other than final releases off of main/master (or other release branches that are supposed to be permanent), you've gone down a very bad path.

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.