Git

Today I learned that you can reference the upstream branch in git with @{u}. I used this to make a convenient git alias reso for “reset to origin”: git config --global alias.reso "reset --keep @{u}" note: I’m using --keep instead of --hard because it’s a bit safer I use this when a branch I’ve pulled down has completely changed on the remote and I have no changes (for instance when reviewing a PR) and a pull would be messy (a reset is also much faster depending on the number of commits). ...

Today I learned that if you need to update (or delete) credentials that were previously saved with the git-credential-manager, then you have to go the Windows Credential Manager. Find it under Control Panel -> Credential Manager -> Generic Credentials. Read more.

If you’ve ever had to abort a rebase or merge but didn’t want to waste the work you already did resolving merge conflicts, then you should enable the git rerere option: git global config rerere.enabled true It stands for Reuse Recorded Resolution, and it essentially remembers how you resolved a merge conflict and will automatically reapply if it sees it again. Resolving conflicts with git-rerere

One of my favorite git plugins is git-absorb (which is a port of Mercurial’s absorb). It basically helps you create --fixup commits automatically, which you can then use an interactive rebase with autoSquash to “absorb” them into your previous commits. I tend to use it when I’ve made a bunch of small tweaks to my feature branch, especially from automated feedback from a PR bot, I’ll then stage the changes and git-absorb will find the previous commit on my branch that also modified those same lines. ...

Today I learned about the git config setting push.autoSetupRemote that was added in version 2.37.0. Like Tekin mentions in his post, I’ve had a git alias to do create my upstream branch but I still forget sometimes. To me this seems safe to enable by default with: git config --global --add --bool push.autoSetupRemote true and git will now set the upstream tracking branch for you!

Today I learned that if you’re using the fairly new --update-refs feature of git to update multiple refs during a rebase, git won’t update a ref if it’s currently checked out in another working directory for that repo. This makes sense but git currently doesn’t give you any feedback that it wasn’t updated or why. It wasn’t until I tried to manually update it with a git branch --force that it told me the issue: ...

Today I learned that you can configure git to use a different diff viewer when displaying diffs from the command line. You do this by setting the pager config git config --global core.pager delta and delta is a cool one written in Rust that can even display line numbers and syntax highlighting. git show produces: Relatedly, it uses the same themes as bat which is a cat command line replacement with syntax highlighting that is pretty nice.

Today I learned that you can ignore commits in Git blame on Github with a .git-blame-ignore-revs file in the root of your repo! I’d known about the git config blame.ignoreRevsFile config option where you can point it to a file with a list of commit IDs to ignore which is especially useful for those annoying commits in a repo where whitespace was cleaned up or every tab in the codebase was replaced with spaces. You have to run the config command locally but now apparently Github does it automatically. ...

Today I learned about the --force parameter of git branch which will take an existing branch and point it to a different commit. This is another handy alternative to git reset --hard for some common scenarios. For example, if I forgot to create a new feature branch and accidentally made some commits onto main, I can run the following: git checkout -b new-branch # create the new branch and switch to it git branch --force main origin/main # fix main back to what it should be vs what I would do before: ...

I just learned that git reset has a --keep parameter. This works the same as --hard except that it won’t discard any uncommitted changes. It’s meant to be used when we want to remove some of the last commits in the current branch but if there could be conflicts between the changes in the commits we want to remove and our uncommitted changes, then the reset is blocked. I’d been using git reset --hard and just double checking I didn’t have anything uncommitted but I’ll be defaulting to --keep except if I’m intentionally trying to clear out my changes.