Verifying tricky git rebases with git range-diff Git’s range-diff command is pretty powerful but I feel like it’s not talked about enough and it could definitely use a nicer UI so I’m Andrew is helping to demystify it.
How to Write Useful Commit Messages I’ve long been a fan of writing more detailed commit messages and this is an excellent write-up on how to do that.
I found a way to stash changes in git without including the branch name in the stash message. This might be a very niche use case but it’s been a minor annoyance for me for some time. If you just want the alias, then add the following to your .gitconfig: [alias] sm = "!f() { git stash || exit 1; rev=$(git rev-parse stash@{0}) && git stash drop stash@{0} || exit 1; git stash store -m \"$1\" $rev; }; f" You can also use this technique for renaming stashes. ...
I just recently discovered that Git 2.35 added the --staged option to the git stash command. This makes it easy to quickly stash only the changes that you’ve staged.
Today I learned that you can use the --patch parameter with several git commands. The --patch parameter is probably most known for interactively staging changes from the cli, but I’ve never really used it because I find GUI clients are much more convenient for this. But apparently you can also use it with restore/checkout to grab specific changes from another branch. git restore --source=branch-name --patch This is something I haven’t seen easily done in any git client. ...
Today I learned that git has a $GIT_DIR/info/exclude file can contain additional patterns of files to ignore but isn’t committed to the repository. For me this is handy for some tooling configuration files that I use personally but don’t want to clutter the main .gitignore of the repo. If there are some files that you want to always ignore, then you can specify a global ignore file in your git config with core.excludesFile. ...
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. ...