Git

I discovered that a reword option was added to --fixup back in git 2.32 The basic command looks like git commit --fixup=reword:<commit> and you can use it like you would the other autosquash commands. I recommend creating an alias for it though. Thanks to this post, I’ve had a fixup alias that uses fzf to select form recent commits so I created a similar one for reword: [alias] reword = "!git log -n 50 --pretty=format:'%h %s' --no-merges | fzf | cut -c -7 | xargs -o -I{} git commit --fixup=reword:{}" Note, if you’re on Windows, you can install fzf via Chocolatey. And you might also be interested in PSFzf which a Powershell module that wraps fzf.

I’ve reviewed quite a few pull requests in recent years and I’ve noticed some less-than-ideal practices when it comes to creating merge commits so I thought I’d list some things you can do to make life a little easier for someone reviewing your code. Make the commit message as useful as possible A lot has been written about how to write good commit messages, but I rarely see the advice applied to merge commits. They may not be the most exciting type of commit, but they’re still very important. ...

Today I learned that sh is not the same thing as bash.

I just recently learned that you can actually cherry pick a range of commits instead of just a single commit: git cherry-pick c1..c3 The above is using the two-dot range notation (..). I was a bit surprised by this because I thought that this was the purpose of rebase --onto — to take a series of commits and apply them one at a time on top of some other commit. Turns out that they both essentially do the same thing (for each commit they call merge-base under the hood and apply a 3-way merge though you can also think of rebase as a series of cherry picks) but one can be more convenient than the other depending on what you’re doing or how you prefer to think of the operation. ...

Today I learned that in Git 2.36, the --remerge-diff option was added to git show. This effectively lets you view any merge conflicts that occurred during a merge commit and how they were resolved. So for instance, git show --remerge-diff <commit-message-id> would show something like: Under the hood, it recreates the merge with the conflicts and diffs it with the merge commit so the conflict markers are shown in red since the merge commit removes the conflict markers during resolution.

Today I learned about the git maintenance command that runs tasks for regular maintenance of a git repo. If you run git maintenance start in a repo, git will create scheduled tasks to run at regular intervals to perform these tasks in the background like garbage collection. This will optimize and speed up the repo without having to tack them on occasionally as you run other commands. A particularly handy task it will run every hour is prefetch, where it does a git fetch but only pulls down the data and doesn’t update any refs. Then when you actually run git fetch or git pull, it completes almost instantly because it already has all the data. ...

Today I learned that ORIG_HEAD is a reference that git maintains to the previous commit HEAD pointed to before it “was modified in a drastic way”. The docs mention these operations as examples of when ORIG_HEAD is updated: (git am, git merge, git rebase, git reset) This is useful when you want to undo one of those operations. You can use git reset --hard ORIG_HEAD (or --keep) to put your branch back to where it was before the operation.

This is probably a very niche use case, but I learned today that you can abbreviate commands that git populates in the todo list during an interactive rebase. So instead of this: pick deadbee The oneline of the commit pick fa1afe1 The oneline of the next commit It’ll look like this: p deadbee The oneline of the commit p fa1afe1 The oneline of the next commit You can enable this with git config --global rebase.abbreviateCommands true. ...

I just discovered the interactive mode of git clean. Git Clean is handy when you want to clear out anything from your local repository folder that isn’t tracked by git. This often includes build outputs and other generated files. This is useful if for instance Visual Studio is acting weird and you’re tempted to do a fresh clone to fix it. I have a git alias I use for this: cl = git clean -idx -e 'node_modules' ...

Today I learned that DeepGit is actually completely free even for commercial use. This is the best git blame utility I’ve come across because it lets you continue drilling down into the history of a line, kinda like a recursive blame. You do have to provide an email address to register but I think it’s worth it. It’s from the same developer of my preferred git client SmartGit but SmartGit does require a paid license for commercial use.