linux-kernel - Re: linux-next: manual merge of the drm 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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKMK7uFVURzdH-NKBaE7CHgbK8QfGtwcQ_12-9T_oVU4PnxK9g@mail.gmail.com>
Date:	Mon, 7 May 2012 10:06:52 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Dave Airlie <airlied@...ux.ie>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: linux-next: manual merge of the drm tree with Linus' tree

On Mon, May 7, 2012 at 5:45 AM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/i915/intel_display.c between commit 074b5e1a99fb
> ("drm/i915: Do not read non-existent DPLL registers on PCH hardware")
> from Linus' tree and I have no idea which commits from the drm tree.

The merge should be pretty simple, the problem is that git gets
completely confused.The offending commits in drm-next are
14415745b2..1fa611065 which simply moves a few functions from
intel_display.c to intel_pm.c. The offending commit in -fixes doesn't
touch these functions at all.

The problem seems to be that git diff gets completely confused:

$ git diff 14415745b2..1fa611065
is a nice mess in intel_display.c, and the diff leaks into totally
unrelated functions, whereas
$git diff --minimal  14415745b2..1fa611065
seems to be exactly what we want.

Unfortunately I haven't found any way to teach similar smarts to the
merge diff and merge conflict generation - with the minimal diff there
really shouldn't be any conflict with this patch

> I fixed it up (I think), but, again, the merge diff is way to log to
> post ...
>
> Again, Dave, can you cherry-pick or merge the commits that affect the drm
> tree from Linus' tree, please?  Surely those fixes are needed in the drm
> tree as well - or if they are not, then let me know and I will just use
> the drm tree's version of this file.

I'll sort this out with Dave. The problem though is that because git
is so confused, almost every intel_display.c patch in -fixes conflicts
with -next. And every time we change something in -next, the confused
diff moves around a bit, making also git rerere pretty useless. So
we'd need a backmarge of -fixes into -next an awful lot of times,
which is why I've held off doing the merge for as long as possible.

Does any of the git gurus have a good idea for how to get myself out
of this corner?

Another thing: Can you please add the new drm/i915 -next tree to
linux-next? With the new drm/i915 -next process we have about 2-3
weeks of lead time between the intel tree and Dave's tree for internal
QA and testing, so that we can sort out these issues earlier:

git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued

[Note the -queued, -next is frozen every 2 weeks so that QA has a
known base for the manual testing cycle.]

Cheers, Daniel
-- 
Daniel Vetter
daniel.vetter@...ll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/