A couple of random addendums (although these aren't necessarily what you'd use day to day)

git diff --color-moved

(seriously, read through the man page for git diff sometime)

git log -p --all -- <path/to/file>

(I use this with multiple remotes, so I can track changes in my fork and in upstream when looking for context around a file)

git cherry-pick -x

(for automatically adding a reference to the original commit)

A couple more, but I think they're really quite specific to my personal workflow and responsibilities

(shameless plug): https://github.com/dandavison/delta is a syntax-highlighting pager for git that adds syntax highlighting and within-line edit detection to all diffs displayed by git.

I agree about `git log -p`. A good trick with that is to use it as a quick way to search for a commit that includes a certain string (since the pager is less, one can search back in time with `/`).

Same trick for `git reflog -p`.

`git stash show -p` is another less-known diff command (look at a stash without applying it).

git log -p --all -- <path/to/file>

I like this one. I'll remember it. Thanks for sharing!

> I got a little tired of running to Google every time I needed a non-trivial git command

Have you read through the gittutorial, gittutorial-2, and especially the gitcore-tutorial manpages[1]? Reading those guides and actually following the steps and examining the results on disk was extremely helpful for me in understanding how Git actually works. Once you've got that understanding, the Git UI seems less arbitrary. You can start to see how it was put together over the years, which should help you use the tool more intuitively and effectively.

> I'm curious to know which workloads might require some of git's more advanced features on a regular basis.

I work on a very large and very old (mid-90s) project, so history-diving and diffing branches is very useful for me. I use all of git-blame, git-show, and git-diff to examine history to learn how the code came to be as it is. Even git-cat-file comes up occasionally when I just want to look at some old object I happen to have a hash for and don't want to look up properly through the porcelain.

We also maintain a bunch of branches and backport modern commits onto legacy branches. git-rebase can help for this, but more often I find myself doing it manually (well, with a bash script) with git-cherry-pick, as it's easier to work with commits without being in the middle of a rebase operation. Knowing git-log's many options to massage history into a useful form for my work comes in very handy here, too.

More details on the rebasing procedure I use: https://github.com/ValveSoftware/Proton/blob/proton_4.11/doc...

Here's some of the tooling I use often. For Git stuff, see pick_commits and gitconfig https://gitlab.com/mywinetools/mywinetools/

[1] I know, I know, no one likes studying and learning how to use a tool. But sometimes you gotta if you want to use the tool effectively.

How much required reading should a version control tool really need before you can use it competently?

Depends on how many features you want it to have, and what level of control over it you want to have, I suppose. It's hardly unique in being a tool one needs training to master. How many programming language books are there? Database theory books? Adobe Photoshop guides? Safety instruction guides for power tools? Best practices for building construction... You have to learn a thing to use a thing. Git is no different.

Your argument seems to be that git, like all change control systems, is powerful and requires explanation. I would counter that there are other change management systems I can explain in 5 minutes, such as Perforce. Git is hard to explain because its model is a mess and few or no people naturally grok the model right away.

While nothing is perfect, I think Git's model is extremely intuitive and easy to work with. Perforce is centralized, isn't it? That's a deal-killer for me. I think we'll just have to agree to disagree, which is perfectly fine :-)

In my professional experience the distributed nature of git isn't used. Individual engineers don't distribute patches or pull branches amongst themselves, there's always still a central repository that is "the repo". Compliance audits of code and build artifacts in the business world pretty much dictates this model.

I think the fact that you can use git locally to work within your perforce workspaces indicates some commonality among the two models, but git has way more features, edge cases, and jargon.

gittutorial I had seen before, but the others I had not. Thanks for that, I'll give them a go.

Wow, mid 90s! Git came out in 2005, so I assume they started out using some previous version control and then switched to git? That must lead to some serious knots. Is there a way to retroactively migrate source control history into git? Depends on the legacy source control tool, I guess.

I think git-blame and git-cat-file are probably the next commands I need to explore in depth. Will investigate those further.

Thanks for sharing your gitconfig as well. Always interesting to see how others are streamlining their workday.

Yes, it was migrated from CVS in 2005[1]. Between then and 1998, it used CVS. Before 1998, It looks like only releases were tracked[2]. I'm not sure what system was used, if any. But yes, it's all migrated into Git, including even the dates.

[1] https://source.winehq.org/git/wine.git/shortlog/ec34a66612d0...

[2] https://source.winehq.org/git/wine.git/shortlog/ebfc0fee51aa...

I use git log -S regularly

https://www.git-scm.com/docs/git-log#Documentation/git-log.t...