linux-kernel - Re: linux-next: manual merge of the tip tree with Linus' tree

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] [day] [month] [year] [list]

Date:	Wed, 21 May 2014 08:10:55 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linus <torvalds@...ux-foundation.org>
Subject: Re: linux-next: manual merge of the tip tree with Linus' tree


* Ingo Molnar <mingo@...nel.org> wrote:

> 
> * H. Peter Anvin <hpa@...or.com> wrote:
> 
> > On 05/20/2014 09:12 PM, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the tip tree got a conflict in 
> > > arch/x86/kernel/ldt.c between commit fa81511bb0bb ("x86-64,
> > > modify_ldt: Make support for 16-bit segments a runtime option")
> > > from Linus' tree and commit 34273f41d57e ("x86, espfix: Make it
> > > possible to disable 16-bit support") from the tip tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary (no
> > > action is required).
> > > 
> > 
> > This (and the previous one) is not the correct fix, although it will
> > work.  The correct fix is instead to completely revert fa81511bb0bb
> > before merging in tip:x86/espfix.
> > 
> > Sorry for the inconvenience.  Linus generally doesn't like it when we
> > fix up merges for him, or I'd set up a "clean" tip:x86/espfix branch.
> 
> Please merge x86/urgent into x86/vdso while memories are still fresh 
> - fixing up conflicts between our own branches is entirely fine (I'm 
> doing it all the time to help the development flow) and it will make 
> life easier.
> 
> What Linus dislikes most are merges between completely _unrelated_ 
> topic branches, especially if they cross maintenance domains.

Also, 'pre pull request' conflict resolution merges are frowned upon 
mostly, as they tend to be of lower quality, come with little testing, 
and they also hide the various conflict interactions, many of which 
are canaries of bad development flow.

Here the development flow is healthy: what conflicted was a quick and 
simple short term urgent fix for upstream which came through you, with 
the longer term fix coming in the next window, through you as well. 

Resolving those conflicts in the development branch, to make developer 
life easier, is pretty natural and I'd say is even considered good 
practice in a clean Git flow.

Thanks,

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