5 ms·

How core Git developers configure Git

317 points by chmaynard 2y ago

MzHN 2y ago
Might be worth mentioning that fsmonitor is Windows and Mac OS only. Also I wish GitHub and GitLab had colorMoved.
- supernaught 2y ago
  Correct, however it looks like fsmonitor might (someday?) be available on Linux too: https://lore.kernel.org/git/pull.1352.git.git.1665326258.gitgitgadget@gmail.com/ https://lore.kernel.org/git/pull.1352.git.git.1665326258.git... Edit: or go third-party? https://github.com/jgavris/rs-git-fsmonitor https://github.com/jgavris/rs-git-fsmonitor I don't have any experience with it though.
do_not_redeem 2y ago
dupe of https://news.ycombinator.com/item?id=43169435 https://news.ycombinator.com/item?id=43169435
wetpaws 2y ago
[dead]
albingroen 2y ago
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 2y ago
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 2y ago
  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 2y ago
  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`
- jmholla 2y ago
  Yea, I enabled those without thinking through all of my use cases and I lost some archived data I didn't intend to. I definitely should've been doing a better job of maintaining those archives, but definitely not an option for everyone.
- krupan 2y ago
  "What would actually happen if I have a branch under development and it gets deleted from remote?" The remote reference would be deleted but your local one would not, and you could push your local right back up to the remote if you want. Pruning is totally safe.
  - larusso 2y ago
    Ok. Was late yesterday. I reread the passage and understood it wrong. Yes if it keeps the „tracking“ branch information in sync that’s ok. I assumed it autocleans local branches. The initial statement regarding history etc kept me off track.
mattmanser 2y ago
This was posted already earlier today, lots of comments on the other thread: https://news.ycombinator.com/item?id=43169435 https://news.ycombinator.com/item?id=43169435
juped 2y ago
Wow, never autopush all your tags. What a terrible idea! Once a tag escapes into the wild, it's so hard to ever get rid of it. Pushing a tag should require two people turning keys simultaneously or something, honestly. zdiff3 is also NOT some kind of generic improvement over diff3, like swapping diff algorithms is sorta a generic improvement. It behaves very differently; if you have [original] this is a line [left branch] This is a line. This is a second line. [right branch] This is a line. This is another line. then diff3 shows <<<<<<< This is a line. This is a second line. ||||||| this is a line ======= This is a line. This is another line. >>>>>>> while zdiff3 modifies this in a very matter-of-personal-taste way to: This is a line. <<<<<<< This is a second line. ||||||| this is a line ======= This is another line. >>>>>>> This is incredibly bizarre to my eye, but some prefer how it's already "partially resolved" for them. But it's hardly something to swap in thoughtlessly for the other!
- hylaride 2y ago
  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.
  - g-b-r 2y ago
    I use tags for all kinds of personal, often temporary, things, so, yeah, no followTags
- ilyagr 2y ago
  +1 on zdiff3. It makes little sense to me; it seems like it can describe different conflicts in the same way. I think diff3 is the only sane choice (the default 2-sided presentation is also somewhat sane, though questionable. It loses important information but is simpler). zdiff3 is described here: < https://git-scm.com/docs/git-merge#_how_conflicts_are_presented https://git-scm.com/docs/git-merge#_how_conflicts_are_presen...>. The example in there makes zdiff3 look quite confusing, since it makes it look as though a line was deleted on both sides. For a while, I thought including the identical line in the base it must be a typo, but apparently that's how it's supposed to work. See also https://lore.kernel.org/git/CAO_smVg=1gFBudrd70V2_AXSPOUTFz=j7QqBpbkvR7P_KqnBtQ@mail.gmail.com/T/#t https://lore.kernel.org/git/CAO_smVg=1gFBudrd70V2_AXSPOUTFz=...
evmar 2y ago
My favorite "took me a long time to discover" Git tweak is to use difft for diffs: https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/
- psyclobe 2y ago
  Couldn't get it to work, constant permission denied errors
- matthberg 2y ago
  An alternative tool that also improves git diff functionality is Delta: https://github.com/dandavison/delta https://github.com/dandavison/delta (personally I think Difftastic's treesitter based approach is superior to Delta, yet I always appreciate it when people link alternatives when discussing apps so thought I'd add this for completeness' sake)
westurner 2y ago
skwp/git-workflows-book > .gitconfig appendix: https://github.com/skwp/git-workflows-book?tab=readme-ov-file#appendix-a---the-gitconfig https://github.com/skwp/git-workflows-book?tab=readme-ov-fil... : [alias] unstage = reset HEAD # remove files from index (tracking) uncommit = reset --soft HEAD^ # go back before last commit, with files in uncommitted state https://learngitbranching.js.org/ https://learngitbranching.js.org/ charmbracelet/git-lfs-transfer: https://github.com/charmbracelet/git-lfs-transfer https://github.com/charmbracelet/git-lfs-transfer jj-vcs/jj: https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj
kibwen 2y ago
The irony here being that GitButler is a GUI for git, whereas most of these config values are for the benefit of the CLI. :P Since they're being too polite to shill themselves, I'll tempt HN by mentioning that GitButler is open-source and will soon be switching its underlying git support from libgit2 to gitoxide (a rewrite of libgit2 in Rust).
- timrod 2y ago
  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/ https://blog.gitbutler.com/gitbutler-is-now-fair-source/
trandingstar 2y ago
[flagged]
deleted 2y ago
[deleted]
yyyk 2y ago
It would be nice to have a way to auto-fastforward other branches when pulling and you have no commits in those branches (There are scripts for that, but it should be in git). Another nice thing would be a way to exclude file specs in git diff (Hack: add 'true' as a diff program in .git/config and use .gitattributes to exclude by setting diff=true).
- matthberg 2y ago
  EDIT: I was wrong and misunderstanding how these options interact, this doesn't solve the stated problem. Still good to have in your config but not as powerful as desired, sorry. Keeping comment contents mostly for posterity's sake. Under the hood `git pull` is just `git fetch`+`git merge` so these two configs together would ideally enable the behavior requested (but unfortunately don't): [fetch] all = true [pull] ff = only I also disable fast-forwarding with `git merge` since I prefer the branch topology you get without it. This doesn't break natural `git pull` fast-forwarding either, thanks to the above config: [merge] ff = false Commands to set all these: git config --global fetch.all true git config --global pull.ff only git config --global merge.ff false
  - yyyk 2y ago
    I meant: (we're in branch A) >git pull ... From ... rev1..rev2 A -> origin/A rev3..rev4 B -> origin/B Updating rev1..rev2 Fast-forward --- The fast-forward is on branch A. I'd like the git pull to also fast-forward branch B (and branches C,D,Etc.). They're usually by other devs, I don't usually check these, but when I do, I could save an extra command when switching if git just moved the branch head with the data it already has.
    - mook 2y ago
      I work around it with: git checkout origin/A There's no reason to clutter `git branch list` output with branches I don't care about.
      - deleted 2y ago
iLemming 2y ago
Tip for Emacs users: One easy way to sort the sections in .gitconfig alphabetically - turn them into org-mode headings. replace-regexp "^[" with "^* ["; then mark-whole-buffer; org-sort; finally, replace the headings back to be normal sections.
schacon 2y ago
Curious what I might have missed that you all put in your `~/.gitconfig`
- wahnfrieden 2y ago
  .DS_Store *.swp
  - infogulch 2y ago
    That's .gitignore. GP is asking about what you have in your .gitconfig.
    - Retr0id 2y ago
      You can however put those in your global `core.excludesfile` path as defined in .gitconfig
  - jmholla 2y ago
    If that last one is vim, you probably actually want `*.sw?` as vim will create a new temporary file if you decided to edit anyway when one exists. It could clobber other tools' file endings, though.
- deleted 2y ago
  [deleted]
- tremon 2y ago
  This is my global gitconfig (minus personal things like user.email etc): [core] pager = [pull] ff = only I don't want git to start a merge without my explicit request, hence the ff-only on git pull. Similarly, opening a pager without me explicitly asking for it is an antipattern and I can't stand tools that do so by default. My terminal has scrollback history TYVM. [push] default = upstream I think this is the default now anyway, but I don't want git assuming anything about remote-local branch relationships. [alias] tlog = log --graph --oneline Simple git tree-log shorthand. [status] showStash = true [stash] showPatch = true I always tend to forget when I stashed something, so I need the explicit reminder. The second one makes git stash more like git show.
videlov 2y ago
> 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 2y ago
  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 2y ago
  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 2y ago
    I imagine it includes things like .DS_STORE.
  - tomjakubowski 2y ago
    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 2y ago
      Similarly, I globally exclude `*.tmp`. I can pipe logs or anything else to some `example.tmp` and never worry about checking them in.
    - dunham 2y ago
      I've been putting a .gitignore file containing a single * inside my scratch directories. But ~/.gitignore sounds like a good idea for local things that I do in every repository.

317 points by chmaynard 2y ago

MzHN 2y ago

Might be worth mentioning that fsmonitor is Windows and Mac OS only. Also I wish GitHub and GitLab had colorMoved.

supernaught 2y ago
Correct, however it looks like fsmonitor might (someday?) be available on Linux too: https://lore.kernel.org/git/pull.1352.git.git.1665326258.gitgitgadget@gmail.com/ https://lore.kernel.org/git/pull.1352.git.git.1665326258.git... Edit: or go third-party? https://github.com/jgavris/rs-git-fsmonitor https://github.com/jgavris/rs-git-fsmonitor I don't have any experience with it though.

do_not_redeem 2y ago

dupe of https://news.ycombinator.com/item?id=43169435 https://news.ycombinator.com/item?id=43169435

wetpaws 2y ago

[dead]

albingroen 2y ago

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 2y ago

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 2y ago
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 2y ago
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`
jmholla 2y ago
Yea, I enabled those without thinking through all of my use cases and I lost some archived data I didn't intend to. I definitely should've been doing a better job of maintaining those archives, but definitely not an option for everyone.
krupan 2y ago
"What would actually happen if I have a branch under development and it gets deleted from remote?" The remote reference would be deleted but your local one would not, and you could push your local right back up to the remote if you want. Pruning is totally safe.
- larusso 2y ago
  Ok. Was late yesterday. I reread the passage and understood it wrong. Yes if it keeps the „tracking“ branch information in sync that’s ok. I assumed it autocleans local branches. The initial statement regarding history etc kept me off track.

mattmanser 2y ago

This was posted already earlier today, lots of comments on the other thread: https://news.ycombinator.com/item?id=43169435 https://news.ycombinator.com/item?id=43169435

juped 2y ago

Wow, never autopush all your tags. What a terrible idea! Once a tag escapes into the wild, it's so hard to ever get rid of it. Pushing a tag should require two people turning keys simultaneously or something, honestly. zdiff3 is also NOT some kind of generic improvement over diff3, like swapping diff algorithms is sorta a generic improvement. It behaves very differently; if you have [original] this is a line [left branch] This is a line. This is a second line. [right branch] This is a line. This is another line. then diff3 shows <<<<<<< This is a line. This is a second line. ||||||| this is a line ======= This is a line. This is another line. >>>>>>> while zdiff3 modifies this in a very matter-of-personal-taste way to: This is a line. <<<<<<< This is a second line. ||||||| this is a line ======= This is another line. >>>>>>> This is incredibly bizarre to my eye, but some prefer how it's already "partially resolved" for them. But it's hardly something to swap in thoughtlessly for the other!

hylaride 2y ago
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.
- g-b-r 2y ago
  I use tags for all kinds of personal, often temporary, things, so, yeah, no followTags
ilyagr 2y ago
+1 on zdiff3. It makes little sense to me; it seems like it can describe different conflicts in the same way. I think diff3 is the only sane choice (the default 2-sided presentation is also somewhat sane, though questionable. It loses important information but is simpler). zdiff3 is described here: < https://git-scm.com/docs/git-merge#_how_conflicts_are_presented https://git-scm.com/docs/git-merge#_how_conflicts_are_presen...>. The example in there makes zdiff3 look quite confusing, since it makes it look as though a line was deleted on both sides. For a while, I thought including the identical line in the base it must be a typo, but apparently that's how it's supposed to work. See also https://lore.kernel.org/git/CAO_smVg=1gFBudrd70V2_AXSPOUTFz=j7QqBpbkvR7P_KqnBtQ@mail.gmail.com/T/#t https://lore.kernel.org/git/CAO_smVg=1gFBudrd70V2_AXSPOUTFz=...

evmar 2y ago

My favorite "took me a long time to discover" Git tweak is to use difft for diffs: https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/

psyclobe 2y ago
Couldn't get it to work, constant permission denied errors
matthberg 2y ago
An alternative tool that also improves git diff functionality is Delta: https://github.com/dandavison/delta https://github.com/dandavison/delta (personally I think Difftastic's treesitter based approach is superior to Delta, yet I always appreciate it when people link alternatives when discussing apps so thought I'd add this for completeness' sake)

westurner 2y ago

skwp/git-workflows-book > .gitconfig appendix: https://github.com/skwp/git-workflows-book?tab=readme-ov-file#appendix-a---the-gitconfig https://github.com/skwp/git-workflows-book?tab=readme-ov-fil... : [alias] unstage = reset HEAD # remove files from index (tracking) uncommit = reset --soft HEAD^ # go back before last commit, with files in uncommitted state https://learngitbranching.js.org/ https://learngitbranching.js.org/ charmbracelet/git-lfs-transfer: https://github.com/charmbracelet/git-lfs-transfer https://github.com/charmbracelet/git-lfs-transfer jj-vcs/jj: https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj

kibwen 2y ago

The irony here being that GitButler is a GUI for git, whereas most of these config values are for the benefit of the CLI. :P Since they're being too polite to shill themselves, I'll tempt HN by mentioning that GitButler is open-source and will soon be switching its underlying git support from libgit2 to gitoxide (a rewrite of libgit2 in Rust).

timrod 2y ago
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/ https://blog.gitbutler.com/gitbutler-is-now-fair-source/

trandingstar 2y ago

[flagged]

deleted 2y ago

[deleted]

yyyk 2y ago

It would be nice to have a way to auto-fastforward other branches when pulling and you have no commits in those branches (There are scripts for that, but it should be in git). Another nice thing would be a way to exclude file specs in git diff (Hack: add 'true' as a diff program in .git/config and use .gitattributes to exclude by setting diff=true).

matthberg 2y ago
EDIT: I was wrong and misunderstanding how these options interact, this doesn't solve the stated problem. Still good to have in your config but not as powerful as desired, sorry. Keeping comment contents mostly for posterity's sake. Under the hood `git pull` is just `git fetch`+`git merge` so these two configs together would ideally enable the behavior requested (but unfortunately don't): [fetch] all = true [pull] ff = only I also disable fast-forwarding with `git merge` since I prefer the branch topology you get without it. This doesn't break natural `git pull` fast-forwarding either, thanks to the above config: [merge] ff = false Commands to set all these: git config --global fetch.all true git config --global pull.ff only git config --global merge.ff false
- yyyk 2y ago
  I meant: (we're in branch A) >git pull ... From ... rev1..rev2 A -> origin/A rev3..rev4 B -> origin/B Updating rev1..rev2 Fast-forward --- The fast-forward is on branch A. I'd like the git pull to also fast-forward branch B (and branches C,D,Etc.). They're usually by other devs, I don't usually check these, but when I do, I could save an extra command when switching if git just moved the branch head with the data it already has.
  - mook 2y ago
    I work around it with: git checkout origin/A There's no reason to clutter `git branch list` output with branches I don't care about.
    - deleted 2y ago

iLemming 2y ago

Tip for Emacs users: One easy way to sort the sections in .gitconfig alphabetically - turn them into org-mode headings. replace-regexp "^[" with "^* ["; then mark-whole-buffer; org-sort; finally, replace the headings back to be normal sections.

schacon 2y ago

Curious what I might have missed that you all put in your `~/.gitconfig`

wahnfrieden 2y ago
.DS_Store *.swp
- infogulch 2y ago
  That's .gitignore. GP is asking about what you have in your .gitconfig.
  - Retr0id 2y ago
    You can however put those in your global `core.excludesfile` path as defined in .gitconfig
- jmholla 2y ago
  If that last one is vim, you probably actually want `*.sw?` as vim will create a new temporary file if you decided to edit anyway when one exists. It could clobber other tools' file endings, though.
deleted 2y ago
[deleted]
tremon 2y ago
This is my global gitconfig (minus personal things like user.email etc): [core] pager = [pull] ff = only I don't want git to start a merge without my explicit request, hence the ff-only on git pull. Similarly, opening a pager without me explicitly asking for it is an antipattern and I can't stand tools that do so by default. My terminal has scrollback history TYVM. [push] default = upstream I think this is the default now anyway, but I don't want git assuming anything about remote-local branch relationships. [alias] tlog = log --graph --oneline Simple git tree-log shorthand. [status] showStash = true [stash] showPatch = true I always tend to forget when I stashed something, so I need the explicit reminder. The second one makes git stash more like git show.

videlov 2y ago

> 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 2y ago
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 2y ago
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 2y ago
  I imagine it includes things like .DS_STORE.
- tomjakubowski 2y ago
  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 2y ago
    Similarly, I globally exclude `*.tmp`. I can pipe logs or anything else to some `example.tmp` and never worry about checking them in.
  - dunham 2y ago
    I've been putting a .gitignore file containing a single * inside my scratch directories. But ~/.gitignore sounds like a good idea for local things that I do in every repository.