1

Suppose I made number of changes in the code and see that code-result unexpectedly has been corrupted. I want to find which change corrupted the result.

It is clear how to find the bugged change if it is contained in some commit.

But how to find the bugged change if it was not in a separate commit, but it was made during history rewriting?

So few days ago I had git history like:

commit00 ( contains no result.txt )
commit01 ( contains no result.txt )
...
commit10 ( contains version1 of result.txt )
commit11 ( contains version1 of result.txt )
...
commit20 ( contains version2 of result.txt )

all versions of results.txt was fine. Then I made few times history rewriting like:

<make changes>
git commit -m "changes to attach to commit0x"
git rebase -i commit0x
<use squash to attach changes to commit0x>

I don't remember which changes I made this way. But now I see that when I go to commit10 or commit20 my program gives different results (not version1 and version2 results).

klm123
  • 12,105
  • 14
  • 57
  • 95
  • `git bisect`, or am I missing something here? – raina77ow Dec 05 '13 at 16:42
  • @raina77ow, may be not. Could you give more specific instructions, please? How to find good version? – klm123 Dec 05 '13 at 16:44
  • Well, there's a detailed explanation [here](http://stackoverflow.com/a/4714297/1229023), but I admit I'm still not 100% sure it's what you need. ) Aren't you trying to find the 'wrong' commit of the ones squashed? – raina77ow Dec 05 '13 at 16:46
  • @raina77ow, at the link the guy talk about revisions.... I don't have good version at any revision, because I have rewritten my history. – klm123 Dec 05 '13 at 16:50
  • Try using `git reflog` to look back in time for a commit before you started squashing your history together. It should still be in there, and you can branch or tag it to resurrect it, and then start reasoning about the differences in that old line and your new, squashed line of development. – Gary Fixler Dec 05 '13 at 16:54

1 Answers1

1

You should be able to use

git reflog

to find the commit(s) before the rebase and go back to that, supposing the rebase was done recently or the log wasn't pruned.

As an example if your git reflog would look like this:

0fe7a44 HEAD@{0}: checkout: moving from b5e056e81aaaf9191dc88f30d54997318f585f5a to master
b5e056e HEAD@{1}: checkout: moving from master to b5e056e81
0fe7a44 HEAD@{2}: rebase -i (finish): returning to refs/heads/master
0fe7a44 HEAD@{3}: rebase -i (continue): add test file
b5e056e HEAD@{4}: rebase -i (start): checkout b5e056e^
69eb9b9 HEAD@{5}: commit: remove test file
b5e056e HEAD@{6}: commit: add test file
f1a96f7 HEAD@{7}: commit (initial): Initial commit.

You could simply check the HEAD you think might contain your changes with

git log HEAD@{6}

or checkout/reset to that as you would with a normal branch.

... hope that'll help.

Sources: git-reflog docs

Herk
  • 181
  • 1
  • 8
  • So I can do "git checkout HEAD@{6}" and test whether this program at this state gave correct results? – klm123 Dec 05 '13 at 17:00
  • Yes, it should treat HEAD@{6} as a branch so you can run checkout/diff/show/log/etc. – Herk Dec 05 '13 at 17:09
  • ok, this helps. +1. But the problem is that I can't test HEAD@{6} dirrectly, because it will correspond to commit0x, and I need commit10. – klm123 Dec 05 '13 at 17:15
  • I suspect you would need to branch off different heads you can find in reflog that match the relevant commits you mentioned and compare the differences or merge them and test your application. – Herk Dec 05 '13 at 17:23