2023-01-10
My Git settings for carrying local changes on top of upstream development
For years now I've been handling my local changes to upstream projects by committing them and rebasing on (Git) pulls, and it's been a positive experience. However, over the years the exact Git configuration settings I wanted to make this work smoothly have changed (due to things such as Git 2.34's change in fast-forward pull settings), and I've never written down all of the settings in one place. Since I recently switched to Git for a big repository where I carry local changes, this is a good time to write them down for my future reference.
My basic settings as of Fedora's Git 2.39.0 are:
git config pull.rebase true git config pull.ff true
The second is there to deal with the Git 2.34 changes, since I have a global pull.ff setting of 'only'.
If you're working with a big repository where you don't really care about which files changed when you pull an upstream update and that output is way too verbose, the normal rebase behavior gives you this. You may also want the following:
git config merge.stat off
This is mostly a safety measure, because normally you aren't merging,
you're rebasing. If you want to still see 'git pull' like output,
you want to set 'git config rebase.stat true' (as I started
years ago).
If you have a repository with a lot of active branches, you may also want:
git config fetch.output compact
This mostly helps if branch names are very long, long enough to overflow a terminal line; otherwise you get the same number of lines printed, they're just shorter. Unfortunately you can't easily get tracking upstream repositories to be significantly more quiet.
If your upstream goes through a churn of branches, you (I) will want to prune now-deleted remote branches when you fetch updates. The condensed version is:
git config remote.origin.prune true
With more Git work, it's possible to pull only the main branch. If I'm carrying local changes on top of the main branch and other branches are actively doing things, this may be what I want. It's relatively unlikely that I'll switch to another branch, since it won't have my changes.
(This may turn out to be what I want with the Mozilla gecko-dev repository, but it does have Firefox Beta and Release as well, and someday I may want convenient Git access to them. I'm not sure how to dig out specific Firefox releases, though.)