OK, how should I have done this...

I just checked in modifications to 1/2 dozen or so files in a single commit and pushed them to my server.

Then I switched to a different machine, pulled the latest version of my repository from the server, tried running my code, and discovered that I introduced a problem that didn't manifest itself when running on my laptop.

So now I want to figure out which modification(s) in which file(s) introduced the problem.

I did a git log and saw that things were fine back at commit 5ccce3, so I did

$ git checkout 5ccce3

fully expecting (and seeing) the warning about 'moving to "5ccce3" which isn't a local branch'

ran my code.  It worked (as expected).

$ git diff --name-status master

Saw the list of files that had changed.

$ git checkout master -- file1

Grabbed the version of file1 from master & reran my test. It passed. Repeated the process until I'd identified the set of 3 files that caused things to break, and fixed those three files.

Now I want to check those 3 files in on the master branch. My first inclination, since every time I've tried doing stuff like this in the past has failed miserably, was to copy those 3 files to a safe location, revert them to their unmodified state, switch to the master branch, copy the modified files into my working directory, and commit them.

Instead, I did:

$ git checkout master

hoping that would just switch me to the master branch, keeping those 3 modified files. Instead, what I got was:

error: Entry 'blah/file7' not uptodate.  Cannot merge.

and now "git status" shows a bunch of files staged to be committed (all the files that were different between master and rev 5ccce3) and my 3 files with their modifications.

I'm gonna go back to plan A, copy those 3 files to someplace safe, and checkout/reset until I get back to a clean checkout of master, copy those 3 files in, and commit that change.

But I _know_ that there must be a better way to do this. What should I have done?

--wpd