linux-kernel - Re: [GIT] Networking

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+55aFzbpYjoJfLnoQy_rGb-FYoh5LKVeTRhp7xX_vXEFk_adA@mail.gmail.com>
Date:	Wed, 16 Jul 2014 17:05:12 -1000
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Kalle Valo <kvalo@...rom.com>
Cc:	"John W. Linville" <linville@...driver.com>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Network Development <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT] Networking

On Wed, Jul 16, 2014 at 4:18 PM, Kalle Valo <kvalo@...rom.com> 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
done.

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.

                     Linus
--
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/