Git Notes: git's coolest, most unloved feature
Git Notes: git’s coolest, most unloved feature - Tyler Cipriani It would be pretty cool if this feature was given some love. Apparently Forgejo now has first-class support for it.
Git Notes: git’s coolest, most unloved feature - Tyler Cipriani It would be pretty cool if this feature was given some love. Apparently Forgejo now has first-class support for it.
The future of large files in Git is Git - Tyler Cipriani I’ve so far managed to avoid having to deal with Git LFS so I’m excited to see that the Git team is working on a better solution. In the mean time I’ll have to try the tip that Tyler gives with git partial clone: git clone --filter='blobs:size=100k' <repo>
An Undefeated Pull Request Template | Ashlee M Boyer This is probably the best and most thorough advice I’ve seen on how to write good pull request descriptions. So many great bits of advice and things I wanted to +1. The first goal of a pull request description is to make code review as straightforward and frictionless as possible. Even if everyone knows the code, you’re saving them time by doing the thinking for them. The code is still fresh in your mind whereas they might need to take a few minutes to recall how the feature works. ...
Today I learned how to create and apply a patch file. If you want to quickly create patch a file from your current changes just run: git diff > mypatch.patch or if like you want just want specific changes then stage then and run: git diff --cached > mypatch.patch then to apply them all you need is git apply mychanges.patch Unfortunately if there are conflicts then will just give you an error: patch does not apply ...
Today I learned that you can share a git config file in a repository for easily sharing certain local config settings with your team. git config --local include.path ../.gitconfig This adds the following to your local config [include] path = ../.gitconfig and will load any config values set in that file. This has a couple advantages in that we only have to run a single git command and if we need to make future changes we only have to update the config file instead of requiring devs to run additional commands to get the update. ...
Working with stacked branches in git (Part 2) Andrew as always has a very handy and thorough post on some advanced git techniques. I’m also a fan of stacked branches but it’s definitely tricky to get the flow right without some extra tooling help.
Today I learned about the --skip-worktree command in git which will treat a file like it hasn’t been modified. This is useful if you have to modify a file locally but don’t ever want to commit it (config files are a common scenario). Like me, you may have seen --assume-unchanged used in this way but that’s not what it’s meant for since it’s “designed for cases where it is expensive to check whether a group of files have been modified”. As a result you’re likely to lose the changes you have made to those files. This post shows a good summary of the outcomes of common operations with each command. ...
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. ...