It can be handy to have two checkouts of a repo. One is the primary one (A) for working in. And the other is the “spare” (B).
This can be useful in a number of situations:
- You’re in the middle of a rebase in A and want to quickly reference something in another branch. Instead of having to mess up your rebase state, or go to github, you just go to B.
- You’re code reviewing an intense refactor of an API. It can be handy to quickly flip back and forth between the versions of the codebase before and after the API change to get a better sense of what changes. Sometimes the diff isn’t quite enough.
- You’re code reviewing one branch and want to quickly code review another in a way that’s “immutable” to your work environment.
- If you want to quickly flip back and forth between builds of two different branches.
I posit that in many software projects there is a small core of the “most interesting” work, surrounded by a larger core of “support engineering”. The “support engineering” is in service of the “most interesting” core in order to make it usable and a good product.
- Compilers: Core optimizations vs cli arg parsing
- Kernels: Core context switching vs some module that prints out the config the kernel was built with
- Audio software: Core engine, data model, or file format work vs UI work on the settings menu
- ChatGPT: Core machine learning vs front end web dev to implement the chat web UI
But the funny thing is that “interesting” is in the eye of the beholder. For every person that thinks X is the “most interesting”, perhaps most technical part of the project, there will be a different person that is totally uninterested in X and is delighted to let someone else handle this for them. This very well may be because X is too technical, too in the weeds.
The generalizes to work and society as a whole — people gravitate towards work that suits their interests. The areas they don’t find interesting are hopefully filled by others who are naturally wired differently. Of course this plays out less cleanly in real life.