From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753127AbaGQDFQ (ORCPT ); Wed, 16 Jul 2014 23:05:16 -0400 Received: from mail-vc0-f172.google.com ([209.85.220.172]:51368 "EHLO mail-vc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751179AbaGQDFO (ORCPT ); Wed, 16 Jul 2014 23:05:14 -0400 MIME-Version: 1.0 In-Reply-To: <877g3cbueb.fsf@purkki.adurom.net> References: <20140715.002844.679028486034873225.davem@davemloft.net> <20140715.114614.827795344549781033.davem@davemloft.net> <20140715190252.GC26012@tuxdriver.com> <877g3cbueb.fsf@purkki.adurom.net> Date: Wed, 16 Jul 2014 17:05:12 -1000 X-Google-Sender-Auth: aWQqVl-ChsI4TqdNiek1aODoMlI Message-ID: Subject: Re: [GIT] Networking From: Linus Torvalds To: Kalle Valo Cc: "John W. Linville" , David Miller , Andrew Morton , Network Development , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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