On Mon, May 7, 2012 at 5:45 AM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 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@xxxxxxxx - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
