linux-kernel - Re: linux-next: manual merge of the arm-soc tree with the arm 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]

Message-ID: <14177423.bqmiv1UdlY@wuerfel>
Date:	Tue, 04 Oct 2011 21:33:48 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Russell King <rmk@....linux.org.uk>,
	Olof Johansson <olof@...om.net>
Subject: Re: linux-next: manual merge of the arm-soc tree with the arm tree

On Tuesday 04 October 2011 08:48:33 Stephen Warren wrote:
> Stephen Rothwell wrote at Monday, October 03, 2011 6:09 PM:
> > Hi Arnd,
> > 
> > Today's linux-next merge of the arm-soc tree got a conflict in
> > arch/arm/mach-tegra/board-seaboard.h between commit ea5abbd215b7 ("ARM:
> > 7101/1: arm/tegra: Replace <mach/gpio.h> with <mach/gpio-tegra.h>") from
> > the arm tree and commit a697e694aeb8 ("ARM: Tegra: Seaboard board updates
> > for audio") from the arm-soc tree.
> > 
> > Just context changes.  I fixed it up (see below) and can carry the fix as
> > necessary.
> 
> Both this and the similar fixup in the other email look fine to me.
> 
> For my education, how does this get resolved; presumably neither Russell's
> tree nor arm-soc can take a patch that fixes this right now, so does one of
> the trees get rebased after the merge of the other but before being pulled
> by Linus, or does Linus do this merge fixup when he pulls?
> 
> Thanks for cluing me in!

Stephen resolves it using git rerere for now, which automatically remembers
the fix. When I start sending patches to Linus, I have the choice to
either do the fixup myself or let Linus do it.

Linus generally wants to see the conflicts and fix them on his own, so that
is the default. If there are complicated merges, I provide another branch
that has the solution so he can compare it with the solution he came up with,
or just take it.

Last time, there was one pull request I sent to Linus that had lots of trivial
conflicts with another branch that I also sent him. Given the same situation,
I would probably just do the merge before I send the pull request.

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