11 ms·

Popular Git config options

446 points by ingve 3y ago

josef_josef 3y ago
[dead]
leetrout 3y ago
Cannot overstate the helpfulness of rerere if you work in a rebase workflow.
- PhilipRoman 3y ago
  Indeed, but be careful not to poison your resolution cache, having a wrong resolution and re-doing a large rebase can be a painful experience.
OJFord 3y ago
Good list, definitely concur with the top ones and can't think of anything major to me that's not listed. rebase.autosquash combined with an alias I have (called 'fixup') to make that commit and then do the rebase is probably my top one by an absolute long shot, at least in terms of frequency of use. pull.rebase is important to me, but I fixup so frequently, I really don't know how people get by without it. (Well, I do, generally they create a snaking history by merging master or whatever into their own branch repeatedly, swapping the parents, and make lots of new commits to fix things in the old ones. But I don't know how you can put up with doing that to yourself, is I suppose the long version of what I mean.) Oh - semi-missed - insteadOf is more useful than implied: I have 'gh:' mapped to the full thing, so I just `git remote add somefork gh:someforker/the-project`, for example. Some other minor ones: advice.statusHints=false; include.path (if you need it you need it - I use it to set my signing key according to which Yubikey is plugged in, plugging can write the whole file because it's all that's in there, no parsing required); remote "origin".fetch set to get PRs; oh and interactive.singleKey = true if that was missed - not a minor one at all! Makes staging changes so much faster and easier. Obviously not as fast as `add .` or `commit -a`, but don't do that.
- oliv3r 3y ago
  I really loved the idea of fixup + rebase, but of course we didn't have an example here :) So I spend half an hour to learn about git shell commands in aliases (had to learn the hardware that arguments require functions) and came up with the following. fixup = "!f() { git commit --fixup ${1} && GIT_SEQUENCE_EDITOR=true git rebase --autosquash --interactive --rebase-merges \"${1}~1\"; }; f" from https://gitlab.com/olliver/dotfiles/-/blob/master/.config/git/config?ref_type=heads#L3 https://gitlab.com/olliver/dotfiles/-/blob/master/.config/gi... Hope this helps anybody else :)
- NewJazz 3y ago
  Another way to get that instead of behavior is with SSH configuration. I have something like this in my ssh config: Host github Hostname github.com User git Then you can do a "git clone github:microsoft/windows" and you're good to go.
  - OJFord 3y ago
    True. If I'm only using it for git though makes sense to keep the config there IMO. But certainly that's handy when you're sshing interactively or doing other things with that host.
  - jerpint 3y ago
    Neat
  - hinkley 3y ago
    This fuckin' guy. If you've evolved an SSO solution from brownfield, or just merged with another company you can easily end up in a spot where you have 2 user names across the systems, and that's before you get into doing things like pushing bug fixes to Github straight from your work machine. Make yourself an .ssh/config file. Set your user, and your ssh key for where it matters (I don't use the same key for ssh to servers and for talking to github or bitbucket)
    - NewJazz 3y ago
deleted 3y ago
[deleted]
oldpersonintx 3y ago
> init.defaultBranch main if you think people who use "master" are doing so because they fervently wish to reconstitute slavery, you may be beyond help even my woke friends who are somewhat rational cringe at this
- striking 3y ago
  `git init` itself hints that you should globally configure an initial branch name in your git config, and suggests "main", "trunk", and "development" as alternatives. It will continue to make this suggestion until you make a choice. Here's the full output from `git init` with no additional config on my machine: hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.defaultBranch <name> hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m <name> Initialized empty Git repository in /private/tmp/test/.git/ I think people that set this actually get to that point because they don't want to keep seeing the warning, and "main" is as good a value as any. In light of this, your harsh moral ascription seems fairly silly.
  - elevatedastalt 3y ago
    This was done precisely following the change that OP is hinting towards. Let's not pretend like this was done for a technical reason.
    - striking 3y ago
      I'm not sure which "this" you're referring to here, but I don't think there's anything wrong with choice. It's like being prompted to choose a browser. Some people choose the default, others prefer Firefox.
      - wakawaka28 3y ago
ComputerGuru 3y ago
How to get all your set git options: git config --global --get-regexp . | sort -u A hack I like that makes diffing possibly minified or formatting-mangled source files easier: diff.css.textconv css-beautify (Unminifies and unifies the formatting of css files before diffing them, might need to have the *.css type set in your .gitattributes though) core.editor nvim (Use neovim as the editor for commit messages and other things)
- NewJazz 3y ago
  You can set the EDITOR env var instead of using core.editor. or setup symlinks with your package manager.
- nerdponx 3y ago
  I use this to get a list of my configured aliases. [alias] ls-alias = config --global --includes --get-regexp 'alias\..*'
  - mkhnews 3y ago
    Same here - [alias] alias = "!git config --get-regexp ^alias. | sed 's/^alias.//'"
    - matijs 3y ago
      ! Is for external commands. You can drop the !git from that alias.
      - nerdponx 3y ago
        Not if you're piping it to sed though, right?
        matijs 3y ago
        Oh! Thanks for clarifying!
peterhadlaw 3y ago
I think a critical one would be: init.defaultBranch master Especially since places like GitHub are making main the default unwittingly
- NewJazz 3y ago
  Wait are you saying to keep the default branch as master explicitly?
  - OJFord 3y ago
    Yes, I do it too. 'master' is too ingrained to change and has nothing to do with slavery or anything sinister IMO. If I ever work with someone on a project we're in control of who feels otherwise and affected personally then it won't be much effort to change it. Until then I don't need to pointlessly spend effort rewriting it when I get it wrong on my own projects. (It only affects what git init does.)
    - ithkuil 3y ago
      Indeed "master" comes from "master copy" which is the version of the "teacher" (magister) from which students copy a work
      - ksenzee 3y ago
        Yes, and as it happens, “master” was a bad metaphor for what that branch actually is and does. It would have been a better metaphor for what is usually called “origin.”
        lobocinza 3y ago
        "main" isn't a better metaphor
        wakawaka28 3y ago
        It's not a bad metaphor at all. I've never met anyone confused by it. People want to change it because of the political grifters, not for want of clarity.
enobrev 3y ago
I see an article by Julia, I upvote it. Always excellent. I learn something every time Julia writes something for us to read.
ryandrake 3y ago
> “80% of people use this, probably take a look” If an option is used by 80% of users, shouldn't it be the default, and have an option to turn it off for the 20%?
- OJFord 3y ago
  Not necessarily I'd say, it could be something that's confusing to a newcomer or (or even doesn't make sense) on first use. But that doesn't exist anyway, that was a wish for it to exist. If the tool had it, it could decide to change the defaults as you say, and so the worth-looking-at number would just be 35% or whatever instead.
yegle 3y ago
Most people on HN probably disabled "usage report" in all places they can. Otherwise it is possible to produce a report on "which option is more popular".
- NelsonMinar 3y ago
  There was an interesting discussion about this problem on Mastodon yesterday started by Julia: https://mastodon.social/@b0rk@jvns.ca/111935753657358820 https://mastodon.social/@b0rk@jvns.ca/111935753657358820 The general conclusion is that relatively few FOSS tools collect usage information the way commercial software now does. Interesting opportunity to potentially improve things.
  - rcoveson 3y ago
    > Interesting opportunity to potentially improve things. ...you mean by changing commercial software to collect telemetry more like FOSS tools do, i.e. usually not at all, right?
    - NelsonMinar 3y ago
      No, that's not what I mean.
    - tstrimple 3y ago
      It's interesting how many people assume telemetry is just for spying on users and not an honest attempt to actually improve the product. Usability on most FOSS tooling is garbage. Even gems like Blender have incredibly rough edges compared to their commercial counterparts and that's one of the best examples of UX in FOSS. If users are spending a disproportionate amount of time performing operation X, I want to zoom in on operation X and find out what is holding them up and if it can be streamlined. I get that a lot of these metrics can be used more nefariously, but if you want to improve something you've first got to measure it or you have no baseline to determine if your "improvement" actually made a difference. Telemetry and usage information is not bad in and of itself. It's a perfectly valid tool that can be used to find rough edges on your product and improve them. It's a great way to determine the most commonly used operations. Every developer who has worked on products used by real people inevitably discovers that their users approach their software in ways completely different than intended. Some of these unintended ways represent valid use cases the developer or product owner never anticipated. If you discover these things, you can improve the product by making that operation a first class operation instead of a weird workaround. If you're not collecting metrics, you're only listening to the most noisy parts of your user base who are by definition a small minority.
Zardoz84 3y ago
I find disturbing that don't mentions kdiff3 with diff and merge tool. Specially when kdiff3 does the smae thing that diff3 and zdiff3 output formats... I don't understand the popularity of meld. I always felt that meld it's pretty inferior to kdiff3. And I give a few try to it...
- cpeterso 3y ago
  My favorite free (though not open source) visual diff and merge tool is Perforce's P4Merge. It's available for Linux, macOS (including as a Homebrew cask), and Windows. My favorite feature is its conflict resolution listing the conflicting lines vertically in the source file (like diff3 conflict markers but a GUI) instead of side-by-side panes. https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge https://www.perforce.com/products/helix-core-apps/merge-diff...
- mistrial9 3y ago
  regular meld user here .. just do not have KDE parts when it can be avoided -- not disagreeing otherwise.
chungy 3y ago
My config: [alias] co = checkout ci = commit st = status br = branch hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short type = cat-file -t dump = cat-file -p dft = difftool [tag] sort = version:refname [tar "tar.xz"] command = xz -c [tar "tar.zst"] command = zstd -T0 -c [log] date = iso-local [pull] ff = only [diff] tool = difftastic [difftool] prompt = false [difftool "difftastic"] cmd = difft "$LOCAL" "$REMOTE" [pager] difftool = true [safe] directory = * [advice] detachedHead = false [init] defaultBranch = master
- xyst 3y ago
  Not a fan of the “main” branch revolution? Pretty good config though. Personally, I use diff configs depending on oss vs personal vs work. So I combine mine with “[includeIf gitdir:~/oss…]” … Some companies like G have some weird requirements.
  - chungy 3y ago
    No, I'm not a fan of it. It's been master since forever and it's a perfectly good term, fits regular English convention of "master branch" too. > Personally, I use diff configs depending on oss vs personal vs work. So I combine mine with “[includeIf gitdir:~/oss…]” … I'd stuff such things into the local repos' .git/config files instead of the global. It's rare that I do it, but sometimes I do work with projects with differing conventions.
    - influx 3y ago
      I liked it more once I realized it was fewer characters to type.
      - worksonmine 3y ago
        Typing 'ma<Tab>' is the same in both cases. I don't like the change because the reason behind the change is political. Give an inch take a mile etc, it's getting out of hand. But I don't care enough to stand out.
ncann 3y ago
pull.ff only should have been the default option, or at least pull.rebase true. I've helped so many git newbie at work and this is probably the thing that caused the most confusion to people. The merge commit resulted from the default pull behavior caused nothing but pain.
- globular-toast 3y ago
  The fundamental thing people fail to understand is the distributed nature of git. They don't understand that their master branch is not the same as your master branch, which isn't the same as GitHub's master branch etc. In fact, every time you clone you are also making a new branch! The default behaviour of pull makes complete sense in the distributed system. It goes wrong when developers are also pushing to remotes and doing feature branches and the like. I love forges like GitHub, but I understood git first. Developers nowadays are using a decentralised version control tool to do centralised version control. No wonder it goes wrong.
xp84 3y ago
At the risk of angering all the vim-heads (this tip isn’t for anyone who likes vim or even emacs): editor = "nano -t" This nano option is aka --saveonexit Things accomplished: - avoids using an overpowered modal editor that requires several keystrokes just to save and quit when done writing my couple of sentence commit message - avoid even having to tell it I want to save. Of course I want to save. ^x - all done (In the unlikely event you decide you want to abort the commit, just hit ^k a few times to kill the text and then ^x) (Edit: Updated to the default exit keybinding which is ^x)
- lobocinza 3y ago
  Sometimes I don't wan't to save. I may have second thoughts and want to change things before committing.
- davidhaymond 3y ago
  That's a nifty option! In (neo)vim, I like to use the ZZ keybinding to quickly save if modified and then quit. If I want to abort the commit, I'll type ZQ to discard changes and quit.
  - sodapopcan 3y ago
    Ya, it's somewhat surprising that ZZ isn't the binding that is burned into people's minds instead of :wq<cr>. I've even met regular vim users who don't know ZZ which, to be a bit hyperbolic, is mindboggling. EDIT: And of course there is vim -y to make vim behave more like a "normal" editor than even nano :D (ie, you get ctrl-s and ctrl-q).
    - jdougan 3y ago
      For me, it's because when I learned BSD 4.2 vi in the mid-80s the emphasis was on learning the decomposed commands then building up. If you learned w and q , wq is obvious and non-magical.
      - sodapopcan 3y ago
realjhol 3y ago
[dead]
Izkata 3y ago
> core.editor emacs: to use emacs (or another editor) to edit commit messages I set EDITOR in my bashrc ages ago, so everything uses my chosen editor, including git. This git setting then overrides it if you use it.
edavis 3y ago
For the "I want to use different emails for different repos" issue, I've seen the `includeIf` technique but it felt fiddly. What I've done is set `user.useConfigOnly = true` and commented out `user.email` in ~/.gitconfig. Now the first time I commit in a new repo, it errors out with "Author identity unknown" and I punch in "git config user.email ADDR" for the email I want to use and re-run the commit.
- NewJazz 3y ago
  Huh. How many repos do you have? And how many emails? I have... A lot of repos. And two emails.
  - thfuran 3y ago
    Two is still more than one, and it seems reasonable to, for example, keep work separate from personal stuff.
    - NewJazz 3y ago
      Yeah, but the includeIf solution has me typing my emails once each, rather than once each for something like 100+ repos.
      - gcarvalho 3y ago
        I occasionally clone repos into /tmp for some small tweaks without switching branches or whatever, and that’s usually when I commit with the wrong email. Neither includeIf nor useConfigOnly are ideal in this scenario because a) it’s cloned in a generic location that can’t be differentiated using path-based includeIf, or b) manually setting it multiple times for the same repo is even more annoying. I’ve tried conditionally setting email based on the remote [1], but for some reason I did not manage to make it work. I didn’t try too hard, and I might try again with more patience. [1] https://www.brantonboehm.com/code/conditional-git-config/ https://www.brantonboehm.com/code/conditional-git-config/
JelteF 3y ago
My personal favorite additions to my git config are using delta[1] as my pager for much more readable and syntax highlighted diffs. And adding the following alias, which means I no can always check out to the default branch of the repo, no matter if it's called master/main/develop/whatever [alias] checkout-default = "!git checkout $(git rev-parse --abbrev-ref origin/HEAD | sed 's@^origin/@@')" [1] https://github.com/dandavison/delta https://github.com/dandavison/delta
prima-facie 3y ago
A few more: Change the comment character. This is useful when you want to include a hash in your commit message (e.g. for automatically linking to JIRA tickets). [core] commentChar = ";" When starting a new branch/ticket you can create an empty commit where you write a detailed subject and description. [alias] newtask = commit --allow-empty Create a zip archive of the current files. [alias] zip = archive -o latest.zip HEAD Switch between the last two active branches with: git checkout - Use short log lines: [format] pretty = format:%C(yellow)%h %Cblue%>(12)%ad %Cgreen%<(7)%aN%Cred%d %Creset%s Some delta tweaks: [delta] features = decorations # line numbers navigate = true # use n and N to move between diff sections And finally: [alias] praise = blame
twic 3y ago
remote.origin.tagOpt=--tags Now, is there any way to set that for all remotes?
- frontalier 3y ago
  remote.*.tagOpts=--tags
  - twic 3y ago
    Apparently not: fatal: bad config line 11 in file /home/twic/src/myproject/git/gitconfig
from-nibly 3y ago
My favorite aliases (these scripts keep working and I wrote them YEARS ago so they might be optimize-able) [alias] fb = !fzf_prompt.sh # prompts the user with an fzf prompt to fuzzy search for branches cheese-touch = "log -n 1 --format=format:'%an' --" # displays who edited a file last destroy = "!git reset HEAD~1 && git add --all . && git reset --hard" # destroys top commit sc = "commit --amend --no-edit" # *jackie chan's uncle voice* one more thing! pushf = "push --force-with-lease" # *lego batman voice* first try! all = "!git add --all . && git status" # I forget that this doesn't exist on everyone's computer. cp = "cherry-pick" # this one feels obvious but that saves me so many letters ---fzf_prompt.sh--- #!/usr/bin/env bash branch=$(git for-each-ref --shell --format='%(refname)' refs | cut -d/ -f3- | grep -Eo "[^']+" | fzf-tmux -d 15); if [[ ! -z "$branch" ]]; then if [[ $branch == origin/* ]]; then branch=$(echo $branch | cut -d/ -f2-) fi git checkout "$branch" fi
- wlonkly 3y ago
  I have to ask -- why cheese-touch?
  - from-nibly 3y ago
    It's from the book diary of a wimpy kid. In the book there is some gross cheese on the street and someone is dared to touch it. Once they touch it they become an outcast, obtain the "cheese touch" and no one wants to talk to them. However once they touch someone else the "cheese touch" transfers to that someone else freeing the original person from being an outcast. So cheese touch is the last person to touch that file. Every time someone touches the file the cheese touch transfers. And if that file broke the build or something you can find out who has the cheese touch on that file and t̶r̶e̶a̶t̶ ̶t̶h̶e̶m̶ ̶l̶i̶k̶e̶ ̶a̶n̶ ̶o̶u̶t̶c̶a̶s̶t̶ ask them nicely if they know what's happening.
    - wlonkly 3y ago
kentonv 3y ago
IMO, git needs to change the default for merge.conflictstyle. The default "merge" style is abysmal, it does not give you enough information to correctly resolve conflicts in isolation -- you have to actually look up the changes separately to understand what each was doing. diff3 gives you sufficient information so you don't have to look up anything. I haven't tried the enhanced versions like kdiff3 or zdiff3 or whatever, it sounds like they may be marginally better, but the difference between the default and diff3 is night and day. I've seen so many new engineers struggle for years not being able to figure out conflicts until someone tells them about diff3. The default here has likely wasted millions of dollars of productivity.
- Too 3y ago
  Even better: Use a visual 3-way mergetool instead of working with the raw text. If that’s too much for you, vscode renders the conflict similar to the raw representation but with pretty “accept mine” buttons next to it.
  - kentonv 3y ago
    Those merge tools typically take the raw conflict markers as input, and cannot give you as nice of a UI if they are two-way markers instead of 3-way. So you still want to change the default conflict style.
    - Too 3y ago
      Typically you just type “git mergetool” and the tool launches without you having to care about the marker format.
      - 63stack 3y ago
        Parent comment is saying that the merge tool is not going to be able to interpret the conflicts in the file without having diff3 configured as the marker format.
        3y ago
CodeIsTheEnd 3y ago
My favorite line in my .gitconfig is an alias that prints out the commit history as a tidy graph. (The default `git log --graph` uses 6 whole lines per commit!) [alias] lg = log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all -n 15 Which I took from this Stack Overflow post: https://stackoverflow.com/questions/1057564/pretty-git-branch-graphs https://stackoverflow.com/questions/1057564/pretty-git-branc...
- ComputerGuru 3y ago
  In case you didn't know about it, `tig` does just that by default (and a whole lot more).
- divbzero 3y ago
  I like how --all reveals forgotten refs.
- mprime1 3y ago
  Simplified version I can type from memory (I.e. on a system where I don’t have my gitconfig aliases): -—graph -—oneline -—color
  - szszrk 3y ago
    You just gave me a lesson "why one should not just paste things he found online into his terminal". Your parameters have Em dash instead of a hyphen... I reinstalled git from dedicated official repositories before I realized my git is not old... the param is indeed incorrect.
    - mprime1 3y ago
      I'm sorry. I should have had a copy-paste warning -- typing from a phone... I knew it was coming.
  - deleted 3y ago
    [deleted]
sandreas 3y ago
My git config: [alias] lg = log --graph --abbrev-commit --decorate --date=format-local:'%Y-%m-%d %H:%M' --format=format:'%C(bold blue)%h%C(reset) | %C(bold green)%ad%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all -n 15 hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --decorate --date=short quick-push = "!f() { git add . && git commit -m \"$1\" && git push; }; f" search = lg -E -i --grep [user] email = xxx name = sandreas [core] ignorecase = false autocrlf = input excludesfile = ~/.gitignore_global [url "https://github.com/"] insteadOf = git@github.com: [url "ssh://git@github.com/sandreas/"] insteadOf = https://github.com/sandreas/ [url "ssh://git@github.com/sandreas/"] insteadOf = git@github.com:sandreas/ The quick-push might be interesting. It calls a function `f`, which is defined before, to git add . git commmit -m "$1" git push This can be used to define small git workflows as alias.
deleted 3y ago
[deleted]
iraqmtpizza 3y ago
defaultBranch = slavemaster has been getting a lot of traction; it helps us not shy away from what we did.
vbezhenar 3y ago
One git option that I almost never see in other people configs is [core] autocrlf = input safecrlf = true It prevents commiting CRLF files and forces you to convert those to LF before commit (you can still override it with gitattributes if necessary). I hate CRLF so much that I spent lots of time digging out this combination of configuration values.
- demurgos 3y ago
  Oh that's great. I always used the following `.gitattributes`: # Enforce `lf` for text files (even on Windows) * text=auto eol=lf I'll try your config too. My current position is that anywhere you can choose between CRLF and LF (git, editor, program output), it should always be LF regardless of the platform. Simple LF just works on Windows, and removing this variation point simplifies so much of code. For example, you can check reproducible outputs or hashing with a single reference value.
amarshall 3y ago
> branch.sort -committerdate, makes git branch sort by most recently used branches No, it makes it sort by the committer date of the commit pointed to by the branch. Personally I find that to be of little use. To actually sort by recently used (i.e. switched-to), I wrote https://github.com/amarshall/git-recent-branches https://github.com/amarshall/git-recent-branches
nektro 3y ago
thanks! got 9 new ones from reading this :)
AntonCTO 3y ago
Some commands are used so often that it makes sense to further shorten them by placing them in `.bash_aliases` or a similar file for your favorite shell: ``` alias gs='git status' alias gl='git log' alias gd='git diff --color-words' alias ga='git add' alias gc='git commit' ```
chrisan 3y ago
I stole these from stackoverflow some time ago. Shows the branches with a bit more useful information [alias] # show a list of local git branches sorted by the commit date branches = "for-each-ref --sort=-committerdate refs/heads --format='%(authordate:short) %(color:yellow)%(objectname:short) %(color:green)%(refname:short)%(color:reset) (%(color:cyan)%(committerdate:relative)%(color:reset)) %(authorname)'" # show a list of local and remote git branches sorted by the commit date branches-remote = "for-each-ref --sort=-committerdate refs/heads refs/remotes --format='%(authordate:short) %(color:yellow)%(objectname:short) %(color:green)%(refname:short)%(color:reset) (%(color:cyan)%(committerdate:relative)%(color:reset)) %(authorname)'"

446 points by ingve 3y ago

josef_josef 3y ago

[dead]

leetrout 3y ago

Cannot overstate the helpfulness of rerere if you work in a rebase workflow.

PhilipRoman 3y ago
Indeed, but be careful not to poison your resolution cache, having a wrong resolution and re-doing a large rebase can be a painful experience.

OJFord 3y ago

Good list, definitely concur with the top ones and can't think of anything major to me that's not listed. rebase.autosquash combined with an alias I have (called 'fixup') to make that commit and then do the rebase is probably my top one by an absolute long shot, at least in terms of frequency of use. pull.rebase is important to me, but I fixup so frequently, I really don't know how people get by without it. (Well, I do, generally they create a snaking history by merging master or whatever into their own branch repeatedly, swapping the parents, and make lots of new commits to fix things in the old ones. But I don't know how you can put up with doing that to yourself, is I suppose the long version of what I mean.) Oh - semi-missed - insteadOf is more useful than implied: I have 'gh:' mapped to the full thing, so I just `git remote add somefork gh:someforker/the-project`, for example. Some other minor ones: advice.statusHints=false; include.path (if you need it you need it - I use it to set my signing key according to which Yubikey is plugged in, plugging can write the whole file because it's all that's in there, no parsing required); remote "origin".fetch set to get PRs; oh and interactive.singleKey = true if that was missed - not a minor one at all! Makes staging changes so much faster and easier. Obviously not as fast as `add .` or `commit -a`, but don't do that.

oliv3r 3y ago
I really loved the idea of fixup + rebase, but of course we didn't have an example here :) So I spend half an hour to learn about git shell commands in aliases (had to learn the hardware that arguments require functions) and came up with the following. fixup = "!f() { git commit --fixup ${1} && GIT_SEQUENCE_EDITOR=true git rebase --autosquash --interactive --rebase-merges \"${1}~1\"; }; f" from https://gitlab.com/olliver/dotfiles/-/blob/master/.config/git/config?ref_type=heads#L3 https://gitlab.com/olliver/dotfiles/-/blob/master/.config/gi... Hope this helps anybody else :)
NewJazz 3y ago
Another way to get that instead of behavior is with SSH configuration. I have something like this in my ssh config: Host github Hostname github.com User git Then you can do a "git clone github:microsoft/windows" and you're good to go.
- OJFord 3y ago
  True. If I'm only using it for git though makes sense to keep the config there IMO. But certainly that's handy when you're sshing interactively or doing other things with that host.
- jerpint 3y ago
  Neat
- hinkley 3y ago
  This fuckin' guy. If you've evolved an SSO solution from brownfield, or just merged with another company you can easily end up in a spot where you have 2 user names across the systems, and that's before you get into doing things like pushing bug fixes to Github straight from your work machine. Make yourself an .ssh/config file. Set your user, and your ssh key for where it matters (I don't use the same key for ssh to servers and for talking to github or bitbucket)
  - NewJazz 3y ago

deleted 3y ago

[deleted]

oldpersonintx 3y ago

> init.defaultBranch main if you think people who use "master" are doing so because they fervently wish to reconstitute slavery, you may be beyond help even my woke friends who are somewhat rational cringe at this

striking 3y ago
`git init` itself hints that you should globally configure an initial branch name in your git config, and suggests "main", "trunk", and "development" as alternatives. It will continue to make this suggestion until you make a choice. Here's the full output from `git init` with no additional config on my machine: hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.defaultBranch <name> hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m <name> Initialized empty Git repository in /private/tmp/test/.git/ I think people that set this actually get to that point because they don't want to keep seeing the warning, and "main" is as good a value as any. In light of this, your harsh moral ascription seems fairly silly.
- elevatedastalt 3y ago
  This was done precisely following the change that OP is hinting towards. Let's not pretend like this was done for a technical reason.
  - striking 3y ago
    I'm not sure which "this" you're referring to here, but I don't think there's anything wrong with choice. It's like being prompted to choose a browser. Some people choose the default, others prefer Firefox.
    - wakawaka28 3y ago

ComputerGuru 3y ago

How to get all your set git options: git config --global --get-regexp . | sort -u A hack I like that makes diffing possibly minified or formatting-mangled source files easier: diff.css.textconv css-beautify (Unminifies and unifies the formatting of css files before diffing them, might need to have the *.css type set in your .gitattributes though) core.editor nvim (Use neovim as the editor for commit messages and other things)

NewJazz 3y ago
You can set the EDITOR env var instead of using core.editor. or setup symlinks with your package manager.
nerdponx 3y ago
I use this to get a list of my configured aliases. [alias] ls-alias = config --global --includes --get-regexp 'alias\..*'
- mkhnews 3y ago
  Same here - [alias] alias = "!git config --get-regexp ^alias. | sed 's/^alias.//'"
  - matijs 3y ago
    ! Is for external commands. You can drop the !git from that alias.
    - nerdponx 3y ago
      Not if you're piping it to sed though, right?
      - matijs 3y ago
        Oh! Thanks for clarifying!

peterhadlaw 3y ago

I think a critical one would be: init.defaultBranch master Especially since places like GitHub are making main the default unwittingly

NewJazz 3y ago
Wait are you saying to keep the default branch as master explicitly?
- OJFord 3y ago
  Yes, I do it too. 'master' is too ingrained to change and has nothing to do with slavery or anything sinister IMO. If I ever work with someone on a project we're in control of who feels otherwise and affected personally then it won't be much effort to change it. Until then I don't need to pointlessly spend effort rewriting it when I get it wrong on my own projects. (It only affects what git init does.)
  - ithkuil 3y ago
    Indeed "master" comes from "master copy" which is the version of the "teacher" (magister) from which students copy a work
    - ksenzee 3y ago
      Yes, and as it happens, “master” was a bad metaphor for what that branch actually is and does. It would have been a better metaphor for what is usually called “origin.”
      - lobocinza 3y ago
        "main" isn't a better metaphor
      - wakawaka28 3y ago
        It's not a bad metaphor at all. I've never met anyone confused by it. People want to change it because of the political grifters, not for want of clarity.

enobrev 3y ago

I see an article by Julia, I upvote it. Always excellent. I learn something every time Julia writes something for us to read.

ryandrake 3y ago

> “80% of people use this, probably take a look” If an option is used by 80% of users, shouldn't it be the default, and have an option to turn it off for the 20%?

OJFord 3y ago
Not necessarily I'd say, it could be something that's confusing to a newcomer or (or even doesn't make sense) on first use. But that doesn't exist anyway, that was a wish for it to exist. If the tool had it, it could decide to change the defaults as you say, and so the worth-looking-at number would just be 35% or whatever instead.

yegle 3y ago

Most people on HN probably disabled "usage report" in all places they can. Otherwise it is possible to produce a report on "which option is more popular".

NelsonMinar 3y ago
There was an interesting discussion about this problem on Mastodon yesterday started by Julia: https://mastodon.social/@b0rk@jvns.ca/111935753657358820 https://mastodon.social/@b0rk@jvns.ca/111935753657358820 The general conclusion is that relatively few FOSS tools collect usage information the way commercial software now does. Interesting opportunity to potentially improve things.
- rcoveson 3y ago
  > Interesting opportunity to potentially improve things. ...you mean by changing commercial software to collect telemetry more like FOSS tools do, i.e. usually not at all, right?
  - NelsonMinar 3y ago
    No, that's not what I mean.
  - tstrimple 3y ago
    It's interesting how many people assume telemetry is just for spying on users and not an honest attempt to actually improve the product. Usability on most FOSS tooling is garbage. Even gems like Blender have incredibly rough edges compared to their commercial counterparts and that's one of the best examples of UX in FOSS. If users are spending a disproportionate amount of time performing operation X, I want to zoom in on operation X and find out what is holding them up and if it can be streamlined. I get that a lot of these metrics can be used more nefariously, but if you want to improve something you've first got to measure it or you have no baseline to determine if your "improvement" actually made a difference. Telemetry and usage information is not bad in and of itself. It's a perfectly valid tool that can be used to find rough edges on your product and improve them. It's a great way to determine the most commonly used operations. Every developer who has worked on products used by real people inevitably discovers that their users approach their software in ways completely different than intended. Some of these unintended ways represent valid use cases the developer or product owner never anticipated. If you discover these things, you can improve the product by making that operation a first class operation instead of a weird workaround. If you're not collecting metrics, you're only listening to the most noisy parts of your user base who are by definition a small minority.

Zardoz84 3y ago

I find disturbing that don't mentions kdiff3 with diff and merge tool. Specially when kdiff3 does the smae thing that diff3 and zdiff3 output formats... I don't understand the popularity of meld. I always felt that meld it's pretty inferior to kdiff3. And I give a few try to it...

cpeterso 3y ago
My favorite free (though not open source) visual diff and merge tool is Perforce's P4Merge. It's available for Linux, macOS (including as a Homebrew cask), and Windows. My favorite feature is its conflict resolution listing the conflicting lines vertically in the source file (like diff3 conflict markers but a GUI) instead of side-by-side panes. https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge https://www.perforce.com/products/helix-core-apps/merge-diff...
mistrial9 3y ago
regular meld user here .. just do not have KDE parts when it can be avoided -- not disagreeing otherwise.

chungy 3y ago

My config: [alias] co = checkout ci = commit st = status br = branch hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short type = cat-file -t dump = cat-file -p dft = difftool [tag] sort = version:refname [tar "tar.xz"] command = xz -c [tar "tar.zst"] command = zstd -T0 -c [log] date = iso-local [pull] ff = only [diff] tool = difftastic [difftool] prompt = false [difftool "difftastic"] cmd = difft "$LOCAL" "$REMOTE" [pager] difftool = true [safe] directory = * [advice] detachedHead = false [init] defaultBranch = master

xyst 3y ago
Not a fan of the “main” branch revolution? Pretty good config though. Personally, I use diff configs depending on oss vs personal vs work. So I combine mine with “[includeIf gitdir:~/oss…]” … Some companies like G have some weird requirements.
- chungy 3y ago
  No, I'm not a fan of it. It's been master since forever and it's a perfectly good term, fits regular English convention of "master branch" too. > Personally, I use diff configs depending on oss vs personal vs work. So I combine mine with “[includeIf gitdir:~/oss…]” … I'd stuff such things into the local repos' .git/config files instead of the global. It's rare that I do it, but sometimes I do work with projects with differing conventions.
  - influx 3y ago
    I liked it more once I realized it was fewer characters to type.
    - worksonmine 3y ago
      Typing 'ma<Tab>' is the same in both cases. I don't like the change because the reason behind the change is political. Give an inch take a mile etc, it's getting out of hand. But I don't care enough to stand out.

ncann 3y ago

pull.ff only should have been the default option, or at least pull.rebase true. I've helped so many git newbie at work and this is probably the thing that caused the most confusion to people. The merge commit resulted from the default pull behavior caused nothing but pain.

globular-toast 3y ago
The fundamental thing people fail to understand is the distributed nature of git. They don't understand that their master branch is not the same as your master branch, which isn't the same as GitHub's master branch etc. In fact, every time you clone you are also making a new branch! The default behaviour of pull makes complete sense in the distributed system. It goes wrong when developers are also pushing to remotes and doing feature branches and the like. I love forges like GitHub, but I understood git first. Developers nowadays are using a decentralised version control tool to do centralised version control. No wonder it goes wrong.

xp84 3y ago

At the risk of angering all the vim-heads (this tip isn’t for anyone who likes vim or even emacs): editor = "nano -t" This nano option is aka --saveonexit Things accomplished: - avoids using an overpowered modal editor that requires several keystrokes just to save and quit when done writing my couple of sentence commit message - avoid even having to tell it I want to save. Of course I want to save. ^x - all done (In the unlikely event you decide you want to abort the commit, just hit ^k a few times to kill the text and then ^x) (Edit: Updated to the default exit keybinding which is ^x)

lobocinza 3y ago
Sometimes I don't wan't to save. I may have second thoughts and want to change things before committing.
davidhaymond 3y ago
That's a nifty option! In (neo)vim, I like to use the ZZ keybinding to quickly save if modified and then quit. If I want to abort the commit, I'll type ZQ to discard changes and quit.
- sodapopcan 3y ago
  Ya, it's somewhat surprising that ZZ isn't the binding that is burned into people's minds instead of :wq<cr>. I've even met regular vim users who don't know ZZ which, to be a bit hyperbolic, is mindboggling. EDIT: And of course there is vim -y to make vim behave more like a "normal" editor than even nano :D (ie, you get ctrl-s and ctrl-q).
  - jdougan 3y ago
    For me, it's because when I learned BSD 4.2 vi in the mid-80s the emphasis was on learning the decomposed commands then building up. If you learned w and q , wq is obvious and non-magical.
    - sodapopcan 3y ago

realjhol 3y ago

[dead]

Izkata 3y ago

> core.editor emacs: to use emacs (or another editor) to edit commit messages I set EDITOR in my bashrc ages ago, so everything uses my chosen editor, including git. This git setting then overrides it if you use it.

edavis 3y ago

For the "I want to use different emails for different repos" issue, I've seen the `includeIf` technique but it felt fiddly. What I've done is set `user.useConfigOnly = true` and commented out `user.email` in ~/.gitconfig. Now the first time I commit in a new repo, it errors out with "Author identity unknown" and I punch in "git config user.email ADDR" for the email I want to use and re-run the commit.

NewJazz 3y ago
Huh. How many repos do you have? And how many emails? I have... A lot of repos. And two emails.
- thfuran 3y ago
  Two is still more than one, and it seems reasonable to, for example, keep work separate from personal stuff.
  - NewJazz 3y ago
    Yeah, but the includeIf solution has me typing my emails once each, rather than once each for something like 100+ repos.
    - gcarvalho 3y ago
      I occasionally clone repos into /tmp for some small tweaks without switching branches or whatever, and that’s usually when I commit with the wrong email. Neither includeIf nor useConfigOnly are ideal in this scenario because a) it’s cloned in a generic location that can’t be differentiated using path-based includeIf, or b) manually setting it multiple times for the same repo is even more annoying. I’ve tried conditionally setting email based on the remote [1], but for some reason I did not manage to make it work. I didn’t try too hard, and I might try again with more patience. [1] https://www.brantonboehm.com/code/conditional-git-config/ https://www.brantonboehm.com/code/conditional-git-config/

JelteF 3y ago

My personal favorite additions to my git config are using delta[1] as my pager for much more readable and syntax highlighted diffs. And adding the following alias, which means I no can always check out to the default branch of the repo, no matter if it's called master/main/develop/whatever [alias] checkout-default = "!git checkout $(git rev-parse --abbrev-ref origin/HEAD | sed 's@^origin/@@')" [1] https://github.com/dandavison/delta https://github.com/dandavison/delta

prima-facie 3y ago

A few more: Change the comment character. This is useful when you want to include a hash in your commit message (e.g. for automatically linking to JIRA tickets). [core] commentChar = ";" When starting a new branch/ticket you can create an empty commit where you write a detailed subject and description. [alias] newtask = commit --allow-empty Create a zip archive of the current files. [alias] zip = archive -o latest.zip HEAD Switch between the last two active branches with: git checkout - Use short log lines: [format] pretty = format:%C(yellow)%h %Cblue%>(12)%ad %Cgreen%<(7)%aN%Cred%d %Creset%s Some delta tweaks: [delta] features = decorations # line numbers navigate = true # use n and N to move between diff sections And finally: [alias] praise = blame

twic 3y ago

remote.origin.tagOpt=--tags Now, is there any way to set that for all remotes?

frontalier 3y ago
remote.*.tagOpts=--tags
- twic 3y ago
  Apparently not: fatal: bad config line 11 in file /home/twic/src/myproject/git/gitconfig

from-nibly 3y ago

My favorite aliases (these scripts keep working and I wrote them YEARS ago so they might be optimize-able) [alias] fb = !fzf_prompt.sh # prompts the user with an fzf prompt to fuzzy search for branches cheese-touch = "log -n 1 --format=format:'%an' --" # displays who edited a file last destroy = "!git reset HEAD~1 && git add --all . && git reset --hard" # destroys top commit sc = "commit --amend --no-edit" # *jackie chan's uncle voice* one more thing! pushf = "push --force-with-lease" # *lego batman voice* first try! all = "!git add --all . && git status" # I forget that this doesn't exist on everyone's computer. cp = "cherry-pick" # this one feels obvious but that saves me so many letters ---fzf_prompt.sh--- #!/usr/bin/env bash branch=$(git for-each-ref --shell --format='%(refname)' refs | cut -d/ -f3- | grep -Eo "[^']+" | fzf-tmux -d 15); if [[ ! -z "$branch" ]]; then if [[ $branch == origin/* ]]; then branch=$(echo $branch | cut -d/ -f2-) fi git checkout "$branch" fi

wlonkly 3y ago
I have to ask -- why cheese-touch?
- from-nibly 3y ago
  It's from the book diary of a wimpy kid. In the book there is some gross cheese on the street and someone is dared to touch it. Once they touch it they become an outcast, obtain the "cheese touch" and no one wants to talk to them. However once they touch someone else the "cheese touch" transfers to that someone else freeing the original person from being an outcast. So cheese touch is the last person to touch that file. Every time someone touches the file the cheese touch transfers. And if that file broke the build or something you can find out who has the cheese touch on that file and t̶r̶e̶a̶t̶ ̶t̶h̶e̶m̶ ̶l̶i̶k̶e̶ ̶a̶n̶ ̶o̶u̶t̶c̶a̶s̶t̶ ask them nicely if they know what's happening.
  - wlonkly 3y ago

kentonv 3y ago

IMO, git needs to change the default for merge.conflictstyle. The default "merge" style is abysmal, it does not give you enough information to correctly resolve conflicts in isolation -- you have to actually look up the changes separately to understand what each was doing. diff3 gives you sufficient information so you don't have to look up anything. I haven't tried the enhanced versions like kdiff3 or zdiff3 or whatever, it sounds like they may be marginally better, but the difference between the default and diff3 is night and day. I've seen so many new engineers struggle for years not being able to figure out conflicts until someone tells them about diff3. The default here has likely wasted millions of dollars of productivity.

Too 3y ago
Even better: Use a visual 3-way mergetool instead of working with the raw text. If that’s too much for you, vscode renders the conflict similar to the raw representation but with pretty “accept mine” buttons next to it.
- kentonv 3y ago
  Those merge tools typically take the raw conflict markers as input, and cannot give you as nice of a UI if they are two-way markers instead of 3-way. So you still want to change the default conflict style.
  - Too 3y ago
    Typically you just type “git mergetool” and the tool launches without you having to care about the marker format.
    - 63stack 3y ago
      Parent comment is saying that the merge tool is not going to be able to interpret the conflicts in the file without having diff3 configured as the marker format.
      - 3y ago

CodeIsTheEnd 3y ago

My favorite line in my .gitconfig is an alias that prints out the commit history as a tidy graph. (The default `git log --graph` uses 6 whole lines per commit!) [alias] lg = log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all -n 15 Which I took from this Stack Overflow post: https://stackoverflow.com/questions/1057564/pretty-git-branch-graphs https://stackoverflow.com/questions/1057564/pretty-git-branc...

ComputerGuru 3y ago
In case you didn't know about it, `tig` does just that by default (and a whole lot more).
divbzero 3y ago
I like how --all reveals forgotten refs.
mprime1 3y ago
Simplified version I can type from memory (I.e. on a system where I don’t have my gitconfig aliases): -—graph -—oneline -—color
- szszrk 3y ago
  You just gave me a lesson "why one should not just paste things he found online into his terminal". Your parameters have Em dash instead of a hyphen... I reinstalled git from dedicated official repositories before I realized my git is not old... the param is indeed incorrect.
  - mprime1 3y ago
    I'm sorry. I should have had a copy-paste warning -- typing from a phone... I knew it was coming.
- deleted 3y ago
  [deleted]

sandreas 3y ago

My git config: [alias] lg = log --graph --abbrev-commit --decorate --date=format-local:'%Y-%m-%d %H:%M' --format=format:'%C(bold blue)%h%C(reset) | %C(bold green)%ad%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all -n 15 hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --decorate --date=short quick-push = "!f() { git add . && git commit -m \"$1\" && git push; }; f" search = lg -E -i --grep [user] email = xxx name = sandreas [core] ignorecase = false autocrlf = input excludesfile = ~/.gitignore_global [url "https://github.com/"] insteadOf = git@github.com: [url "ssh://git@github.com/sandreas/"] insteadOf = https://github.com/sandreas/ [url "ssh://git@github.com/sandreas/"] insteadOf = git@github.com:sandreas/ The quick-push might be interesting. It calls a function `f`, which is defined before, to git add . git commmit -m "$1" git push This can be used to define small git workflows as alias.

deleted 3y ago

[deleted]

iraqmtpizza 3y ago

defaultBranch = slavemaster has been getting a lot of traction; it helps us not shy away from what we did.

vbezhenar 3y ago

One git option that I almost never see in other people configs is [core] autocrlf = input safecrlf = true It prevents commiting CRLF files and forces you to convert those to LF before commit (you can still override it with gitattributes if necessary). I hate CRLF so much that I spent lots of time digging out this combination of configuration values.

demurgos 3y ago
Oh that's great. I always used the following `.gitattributes`: # Enforce `lf` for text files (even on Windows) * text=auto eol=lf I'll try your config too. My current position is that anywhere you can choose between CRLF and LF (git, editor, program output), it should always be LF regardless of the platform. Simple LF just works on Windows, and removing this variation point simplifies so much of code. For example, you can check reproducible outputs or hashing with a single reference value.

amarshall 3y ago

> branch.sort -committerdate, makes git branch sort by most recently used branches No, it makes it sort by the committer date of the commit pointed to by the branch. Personally I find that to be of little use. To actually sort by recently used (i.e. switched-to), I wrote https://github.com/amarshall/git-recent-branches https://github.com/amarshall/git-recent-branches

nektro 3y ago

thanks! got 9 new ones from reading this :)

AntonCTO 3y ago

Some commands are used so often that it makes sense to further shorten them by placing them in `.bash_aliases` or a similar file for your favorite shell: ``` alias gs='git status' alias gl='git log' alias gd='git diff --color-words' alias ga='git add' alias gc='git commit' ```

chrisan 3y ago

I stole these from stackoverflow some time ago. Shows the branches with a bit more useful information [alias] # show a list of local git branches sorted by the commit date branches = "for-each-ref --sort=-committerdate refs/heads --format='%(authordate:short) %(color:yellow)%(objectname:short) %(color:green)%(refname:short)%(color:reset) (%(color:cyan)%(committerdate:relative)%(color:reset)) %(authorname)'" # show a list of local and remote git branches sorted by the commit date branches-remote = "for-each-ref --sort=-committerdate refs/heads refs/remotes --format='%(authordate:short) %(color:yellow)%(objectname:short) %(color:green)%(refname:short)%(color:reset) (%(color:cyan)%(committerdate:relative)%(color:reset)) %(authorname)'"