[HN Gopher] Popular Git config options
___________________________________________________________________
Popular Git config options
Author : ingve
Score : 172 points
Date : 2024-02-16 17:43 UTC (5 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| leetrout wrote:
| Cannot overstate the helpfulness of rerere if you work in a
| rebase workflow.
| PhilipRoman wrote:
| 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 wrote:
| 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.
| NewJazz wrote:
| 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 wrote:
| 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 wrote:
| Neat
| hinkley wrote:
| 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)
| oldpersonintx wrote:
| > 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 wrote:
| `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.
| mariusor wrote:
| It's not clear what you're complaining about here. The fact
| that many people use this option, the fact that Julia included
| it in the article, or the fact that it's an option to change
| the default branch name in the first place.
|
| Also it's pretty sad that this is the only part of a very
| informative article that you deigned to comment about.
| athorax wrote:
| I think most people don't even remotely care about master vs.
| main, but it definitely gives me pause when someone is so
| bothered by another persons choice not to use master.
| IshKebab wrote:
| I care, because it introduced a ton of unnecessary pain into
| my workflow. Yes really. I now have a mix of repos using
| `master` and `main`, and I have to remember which one to use.
|
| One repo uses `master` but a subtree uses `main`. If you make
| a mistake and checkout `main` you end up clobbering your
| whole working tree with the subtree.
|
| I also have tooling that used to happily assume `master`,
| which worked fine 99% of the time. Now it works 50% of the
| time, and even worse the name of the main branch is just a
| convention, so you can't even read a setting to see which one
| to use.
|
| I don't care about the specific name. `main` would definitely
| have made more sense from the start (classic terrible Git
| naming). But I do care about pointlessly changing it and
| breaking everything.
| athorax wrote:
| I think the fact that so many tools were setup to assume
| `master` and have no way to configure it differently was
| the real problem, and as annoying as it was to have GH
| switch to `main` it did force a lot of tools to be updated
| to make that configurable. Whether you use main, master,
| trunk, development, or anything else, the fact is the name
| is arbitrary and treating it any other way was incorrect.
| chronial wrote:
| > One repo uses `master` but a subtree uses `main`. If you
| make a mistake and checkout `main` you end up clobbering
| your whole working tree with the subtree.
|
| If you replace checkout with switch/restore, that foot gun
| goes away.
| ComputerGuru wrote:
| 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 wrote:
| You can set the EDITOR env var instead of using core.editor. or
| setup symlinks with your package manager.
| nerdponx wrote:
| I use this to get a list of my configured aliases.
| [alias] ls-alias = config --global --includes --get-
| regexp 'alias\..*'
| mkhnews wrote:
| Same here -
|
| [alias] alias = "!git config --get-regexp
| ^alias. | sed 's/^alias.//'"
| peterhadlaw wrote:
| I think a critical one would be: init.defaultBranch master
|
| Especially since places like GitHub are making main the default
| unwittingly
| NewJazz wrote:
| Wait are you saying to keep the default branch as master
| explicitly?
| OJFord wrote:
| 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 wrote:
| Indeed "master" comes from "master copy" which is the
| version of the "teacher" (magister) from which students
| copy a work
| ksenzee wrote:
| 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."
| nerdponx wrote:
| I found that `main` was actually easier to type and say
| than `master`. You should keep doing what you're doing of
| course. But now that the change is becoming popular, I'm
| happy to keep using it, even in the absence of any
| particular moral reasoning.
| euroderf wrote:
| > 'master' is too ingrained to change
|
| This typifies why the US still runs on imperial units, not
| metric. Don't crush that dwarf, hand me the 16mm pliers.
| IshKebab wrote:
| Well sure, except metric has big advantages over
| imperial, whereas `main` is very very slightly easier to
| type than `master`...
| kstrauser wrote:
| I was used to typing "master", too. I also think a bit much
| was made of using "master" (although using it together with
| "slave" in other contexts does kinda highlight the problem
| people have with it).
|
| But you know, some people around me strongly dislike
| calling it "master". I don't have strong feelings about it.
| They do. Their desire to call it something else is far
| greater than any desire I might have to not to. Switching
| to "main" cost me nothing, saves a couple keystrokes, and
| makes other people happy. Fine, let's do it.
|
| If you want to use "master" on your own internal projects,
| go for it. No one's stopping you. I definitely wouldn't use
| it on a shared project because the potential cost of
| irritating someone isn't worth it. And because I don't want
| to have one set of muscle memory for my own projects and
| another for shared projects, I just use "main" everywhere.
| hiccuphippo wrote:
| It has nothing to do with slavery yes, but main is shorter
| to type. It didn't take much effort to switch when I
| started working in a project that used it.
| threemux wrote:
| Agreed I have this in my gitconfig. The changing of this
| setting caused more damage than "master" ever did
| enobrev wrote:
| I see an article by Julia, I upvote it. Always excellent. I learn
| something every time Julia writes something for us to read.
| ryandrake wrote:
| > "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 wrote:
| 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 wrote:
| 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 wrote:
| There was an interesting discussion about this problem on
| Mastodon yesterday started by Julia:
| 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 wrote:
| > 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 wrote:
| No, that's not what I mean.
| Zardoz84 wrote:
| 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 wrote:
| 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...
| mistrial9 wrote:
| regular meld user here .. just do not have KDE parts when it
| can be avoided -- not disagreeing otherwise.
| chungy wrote:
| 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
| ncann wrote:
| 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.
| xp84 wrote:
| 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)
| davidhaymond wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-16 23:00 UTC)