linux-kernel - Re: [PATCH] fix adbhid mismerge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071017161821.GB15918@atjola.homenet>
Date:	Wed, 17 Oct 2007 18:18:21 +0200
From:	Björn Steinbrink <B.Steinbrink@....de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Al Viro <viro@....linux.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix adbhid mismerge

On 2007.10.16 19:21:53 -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 16 Oct 2007, Linus Torvalds wrote:
> > 
> > I don't think you did anything wrong. You used both --full-history 
> > (implicitly: git-whatchanged) and you made sure to see the diffs for both 
> > sides of any merge (-m), and that means that you should see every single 
> > diff involved.
> 
> Btw, if anybody can come up with a better way to find these kinds of 
> mis-merges, I'd love to hear about it.
> 
[...]
> 
> What I'd actually really like would be something that shows the original 
> conflict, but that's really expensive to compute (it basically involves 
> re-doing the merge from scratch - finding the proper base commit(s) etc). 
> So we never did that.

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/