commit

git diff against previous

March 30, 2025 Linux No comments , , , ,

I’ve been using a simple home grown script (gitdiffc) to generate git diffs against the previous version for all files in a given commit.  It would run something like:

# git diff \
$(git log --pretty=format:%h -2 --reverse d86cc4b38db | tr "\n" " ")

The git log part, just gives two commit IDs. Example:

# git log --pretty=format:%h -2 --reverse d86cc4b38db
38aeb009b21
d86cc4b38db

I have a few files that I have to manually merge, as there are two many cherry-pick conflicts, so I was collecting information for that merge.  That included extracting the version that I would have wanted to cherry-pick, since :

git show d86cc4b38db:foo.cc > foo.cc.show

I also wanted a diff, of just that file, in the branch I am trying to pick from, but wasn’t sure how to get that easily without looking up the log, like I did in my ‘gitdiffc’ script that ran the log and diff command above.

I figured there had to be an easier way. Shout out to Grok, which pointed out that I can just use:

git diff d86cc4b38db^ d86cc4b38db -- foo.cc

This also means that I can simplify my ‘gitdiffc’ script so that it just runs:

# git diff d86cc4b38db^..d86cc4b38db

eliminating the nested git log command. That is simple enough that I don’t even need a script to remember how to do it. This should have been obvious, since I’ve used HEAD^ just like that so many times (i.e.: git reset HEAD^, to break up the last commit.)

splitting the last git commit into two

April 23, 2020 C/C++ development and debugging. , ,

In the blog post, Split a commit in two with Git, Emmanuel provides a super clear explanation of how to split an old commit into multiple commits, separating that commit into different commits, each with a subset of the files initially committed.

It took me a while before I could figure out how to apply this to the very last commit.  Here’s the required git magic:

git log -n 1 > m
git reset HEAD^
git add ...
git commit -m "First part"
git add ...
git commit -m "Second part"

The differences are really to just skip the first and last rebase steps (don’t do an interactive rebase, and don’t continue that rebase when done.) This was probably obvious to the author of the more general instructions.

Note that before resetting HEAD to the previous commit, I collect the current commit message, under the assumption that portions of it will be used in either of the two (or more) new commit messages.  If you don’t do that, you can fish it out of your history by looking at ‘git reflog’ to see what the message was before mucking around with HEAD.