On Fri, May 4, 2018 at 9:39 PM, Dave Airlie <airl...@gmail.com> wrote: > On 5 May 2018 at 00:10, Jani Nikula <jani.nik...@linux.intel.com> wrote: >> On Fri, 04 May 2018, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: >>> Now that we experiment with dim for drm-next it's much more likely >>> that pull requests have conflicts. But also that dim already knows >>> about them, in the recent drm-intel-next pull it resolve 7/8 >>> conflicts. >> >> I'll bet rerere will be really appealing for Dave. But until now we've >> been able to shrug off potential bogus conflict resolutions with the >> thought that it's just for drm-tip and not for real. Now it'll be for >> real. *gasp*. > > Yeah I do have this worry myself, I spend a lot of time with git log, blame > on every conflict I get to make sure I can definitely say I tried to > understand it, > I have to trust that others are going to put this sort of effort in, > esp for drivers > that aren't theirs.
One upshot of reusing conflict resulutions is at least for i915 our CI will have tested it fully. We pre-merge test all the patches (except when fools like me screw it up), I think merge resolutions should be tested too before becoming part of permanent history. I think the bigger issue is when there's conflicts outside of i915 or core code used by i915, since that's not all that well-tested really. In the past we've mostly gotten those in through forwarding your drm-next or drm-fixes trees in drm-tip (since we don't backmerge directly from Linus' tree, that's where new stuff by other drivers first shows up). As long as you use dim to push drm-next it'll be you who'll do the merge resolution in drm-tip, but with the upside that you can get it tested before it's baked into a permanent merge. Ideally we'd get everyone with a CI (AMD hopefully soon too) to test drm-tip to make sure the preliminary merges are actually good. Once we have that I think reusing the stored conflict resolutions is actually good. Aside: Everyone once in a while someone pushes a broken merge resolution to drm-tip. If that happens all you need to do is revert the offending commit from the drm-rerere branch (or multiple, if there are) and the stored conflict should be gone from all places git can get at it (in the past you had to run a special dim revert cmd, but we reworked how the drm-rerere branch works to make this simpler). Running dim rebuild-tip will then show you the conflict again, and you can try another stab at it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools
