strace is very powerful, but probably not the tool I would jump to at first to solve this mystery. Instead, just go to the source code. Being able to read, interpret, understand, and, eventually, modify other peoples' code is a foundational skill both for industry and open source work. Reading code is often harder than writing code, too, so it's a worthwhile outlet for your natural curiosity, too. (For this particular mystery, you also could have tried Git's own tracing via setting GIT_TRACE=1 in your environment; many tools, especially ones that work over a network, offer some kind of debugging or tracing).
I tend to keep a copy of glibc, Python, coreutils, openssl, and binutils laying around for random grep'ing. I also sometimes keep other more specific tools and libraries laying around, depending on what I'm working on. And, of course, whatever code you use at your place of work.
If you want to have some fun, strace strace to see how it works. Or strace lsof, or ps, or df, or other tools that inspect the state of your system.
strace is a very good first tool to use. It's extremely quick and easy to run, and gives a wonderful view of how the process interacts with the system or other processes. You also notice quickly if you can't find your answer with strace, if what you are interested in is not done with a syscall.
In the source code you are looking at layers over layers of abstraction, variables being passed around and mangled and substituted into strings, maybe get into a dependency tree of various libraries.
Not to say that you are wrong, the source the ultimate most powerful tool and absolutely you should learn to use it. But I disagree with what tool to use first, if you have zero knowledge about the process.
> strace is very powerful, but probably not the tool I would jump to at first to solve this mystery. Instead, just go to the source code.
Though from a learning perspective, it might be useful to play with something like git using strace then compare with what you find in the code. This could help you learn how to interpret results when you don't have access to the code when diagnosing something else later.
I tend to keep a copy of glibc, Python, coreutils, openssl, and binutils laying around for random grep'ing. I also sometimes keep other more specific tools and libraries laying around, depending on what I'm working on. And, of course, whatever code you use at your place of work.
If you want to have some fun, strace strace to see how it works. Or strace lsof, or ps, or df, or other tools that inspect the state of your system.