On Mon, Nov 22, 2010 at 7:05 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. Thanks Junio, that's exactly what I was trying to do. I keep getting confused about checkout vs. reset. Both affect the index and the working copy. Both manipulate the ref pointer. I just can't keep straight when I should use reset. I understand using checkout to grab a particular version of the repository. But your recipe is what I wanted to do. I just used "checkout" instead of "reset --soft". Thanks again. --wpd -- 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