On 2007.10.16 19:21:53 -0700, Linus Torvalds wrote:
[...]
So here's what I came up with:
git grep -l "int keycode, up_flag" \
$(git-rev-list HEAD --parents -- drivers/macintosh/adbhid.c | \
egrep '(.{40} ?){3}' | cut -d' ' -f1) \
-- drivers/macintosh/adbhid.c | grep -o '^[^:]*'
Which gives: b981d8b3f5e008ff10d993be633ad00564fc22cd
Then:
git checkout b981d8b3f5e008ff10d993be633ad00564fc22cd^1
git merge b981d8b3f5e008ff10d993be633ad00564fc22cd^2
And you got your merge conflict.
The idea is, that the above ugliness searches for the last commit that
produced the bad line. The inner git-rev-list call searches for merge
commits (thanks to Ilari in #git for the egrep trick), then git-grep
looks which of these have the "bad line" and the final grep just filters
the filename out.
If the bash thing spits out more than one commit hash, you probably want
to use the last one... I guess... And if the given result doesn't
produce the request merge conflict, well, I guess you could replace HEAD
in the git-rev-list call with the sha1 you got in the first run, but I'm
not entirely sure about that.
Is that helpful?
Björn
-
