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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 16 Jul 2014 17:05:12 -1000
From:	Linus Torvalds <>
To:	Kalle Valo <>
Cc:	"John W. Linville" <>,
	David Miller <>,
	Andrew Morton <>,
	Network Development <>,
	Linux Kernel Mailing List <>
Subject: Re: [GIT] Networking

On Wed, Jul 16, 2014 at 4:18 PM, Kalle Valo <> wrote:
> Just out of curiosity, what is the best way to send a proposal how to
> fix a merge conflict? For example, if I send a pull request to John
> which I know will issue a conflict it would be nice to include
> instructions (or some sort of patch) how I think it should be resolved.

So from personal experience seeing lots of different explanations, my
preferred one is not so much a patch, as explaining *why* something
generates a merge conflict.

Optimally for each conflict, say what happened ("X changed Y, A
changed B close by") and then describe the result in those terms (eg
"pick the code from my branch, but then do the rename of xyz to abc
that caused the conflict", or "pick your side, it obsoletes the fix
from me that causes the conflict" or whatever).

And if you have a *lot* of conflicts, explain why that happaned too,
and think very hard about whether what you do is perhaps screwed up
(or complain about the other entity that did annoying whitespace
changes for no good reason or whatever). Maybe it's just that the
source code is badly organized, but more likely it's because somebody
is just doing something stupid, and people are stepping on each others
toes. If the explanation is "this is a one-time issue brought on by
xyz", then that's fine - sh*t happens. If it's something else, at
least mention it. And if it keeps happening, something needs to be

And in the end, I personally tend to always resolve the conflicts
*without* really looking at the explanation, by just trying to figure
it out on my own. I've had people send me incorrect resolution
suggestions, and I've also occasionally just screwed up my own
resolution. Having somebody elses explanations of what they did is a
good sanity check that things went right (when their explanation
matches mine), and is a good red flag about "maybe this is more
complicated than I thought" when the explanations and results don't
match up.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists