Patrick Doyle <wpdster@xxxxxxxxx> writes: > But I _know_ that there must be a better way to do this. What should > I have done? Depends on how you wanted to fix your history (we already know from your description what shape of tree you want to end up in). If you want to pretend that you were perfect and never made mistakes in these three files you had to fix later, then history surgery like what Matthieu suggested would be necessary (I won't repeat how). On the other hand, if you want to record what you did in the time order, then I would probably do this: $ git checkout master ; test ;# broken $ git checkout 5ccce3 ; test ;# ok $ git checkout master -- file1 ; test ;# ok $ git checkout master -- file2 ; test ;# ok $ git checkout master -- blah/file7 ; test ;# broken $ edit blah/file7 ; test ;# ok $ git reset --soft master $ git commit -a -m 'The change to file3 was borked on the other env' -e and in this particular case, this would be what I would have done, as a separate "fix-up" commit will give me a place to describe why a solution different from the initial attempt, which was Ok on the original machine, was necessary. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html