Patrick Doyle [off-list ref] 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.
On Mon, Nov 22, 2010 at 7:05 PM, Junio C Hamano [off-list ref] wrote:
Patrick Doyle [off-list ref] writes:
quoted
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