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!)
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.
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.
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.
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)
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.
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.
Never used Mercurial in any serious capacity. The abbreviations mostly stem from CVS and Subversion experience (and really glad I haven't touched either in many years).
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.
I also don't like the `includeIf`, but I ended up with a completely different way of doing things.
I just use different accounts depending on the context, usually by either SSH or by starting a Docker container with all the environment already configured.
At least for me, using different identities[1] when I want to use different identities[2], seems less brittle and less likely for my future self to accidentally forget to do something (e.g. change a config when I reinstall an OS).
[1]: OS user, directly (SSH) or indirectly (container).
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.
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.
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
Readit News
Deleted Comment
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.
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)
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/gi...
Hope this helps anybody else :)
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.
> 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.
Why not 'canon'?
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.
I just use different accounts depending on the context, usually by either SSH or by starting a Docker container with all the environment already configured.
At least for me, using different identities[1] when I want to use different identities[2], seems less brittle and less likely for my future self to accidentally forget to do something (e.g. change a config when I reinstall an OS).
[1]: OS user, directly (SSH) or indirectly (container).
[2]: Email address, username, etc.
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.
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).
When starting a new branch/ticket you can create an empty commit where you write a detailed subject and description. Create a zip archive of the current files. Switch between the last two active branches with: Use short log lines: Some delta tweaks: And finally:[alias]