[HN Gopher] How core Git developers configure Git
___________________________________________________________________
How core Git developers configure Git
Author : chmaynard
Score : 184 points
Date : 2025-02-22 12:23 UTC (3 days ago)
(HTM) web link (blog.gitbutler.com)
(TXT) w3m dump (blog.gitbutler.com)
| schacon wrote:
| Curious what I might have missed that you all put in your
| `~/.gitconfig`
| wahnfrieden wrote:
| .DS_Store
|
| *.swp
| infogulch wrote:
| That's .gitignore. GP is asking about what you have in your
| .gitconfig.
| videlov wrote:
| > 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.
| npteljes wrote:
| 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.
| g4zj wrote:
| 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?
| Vinnl wrote:
| I imagine it includes things like .DS_STORE.
| tomjakubowski wrote:
| 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.
| jjayj wrote:
| Similarly, I globally exclude `*.tmp`. I can pipe logs or
| anything else to some `example.tmp` and never worry about
| checking them in.
| MrJohz wrote:
| You would normally use both this and a project-specific
| gitignore.
|
| The project-specific file is for stuff that should be shared
| amongst all users of a particular project. So for a Node
| project you might have `node_modules` in there, for a Python
| project you might have `.venv` and `*.pyc`. If your project
| uses env files, you might have a line like `.env` in there
| for that.
|
| Meanwhile, the global gitignore is for stuff that's specific
| to your system. If you're on MacOS, you might have an entire
| for `.DS_Store`, or if you use Vim a lot you might have an
| entry for `*~` files (i.e. vim backup files). This is stuff
| that's specific to you.
|
| Git can then combine the project-specific ignores (located in
| the project respiratory) and your user-specific ignores
| (located in your global gitignore file), and ignores anything
| that matches either case.
| jcalvinowens wrote:
| Agreed, I don't want my checkout implicitly ignoring a file
| somebody else's checkout wouldn't.
| idle_zealot wrote:
| 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.
| zaptheimpaler wrote:
| 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
|
| I find it really nice to just keep all that in one place and
| not have to configure it per project. There's nothing too broad
| or situational in there that might get in the way - those kinds
| of things can go into the project specific .gitignores.
|
| There's also `git status --ignored` to check if you're missing
| anything.
| dkarl wrote:
| I always put IDE-specific ignores in a global gitignore since
| not every project gitignore has an entry for every IDE.
| isaacremuant wrote:
| 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.
| MzHN wrote:
| Might be worth mentioning that fsmonitor is Windows and Mac OS
| only.
|
| Also I wish GitHub and GitLab had colorMoved.
| supernaught wrote:
| 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.
| do_not_redeem wrote:
| dupe of https://news.ycombinator.com/item?id=43169435
| albingroen wrote:
| 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.
| larusso wrote:
| 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.
| juped wrote:
| 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.)
| T-Winsnes wrote:
| 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`
| mattmanser wrote:
| This was posted already earlier today, lots of comments on the
| other thread:
|
| https://news.ycombinator.com/item?id=43169435
___________________________________________________________________
(page generated 2025-02-25 23:00 UTC)