Re: Forced push done to drm-intel-next-queued

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 15-01-19 10:56, Daniel Vetter wrote:
On Thu, Dec 27, 2018 at 04:24:51PM +0100, Hans de Goede wrote:
Hi,

On 27-12-18 15:42, Jani Nikula wrote:
On Tue, 25 Dec 2018, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Hi,

As mentioned in the "I messed up drm-intel-next-queued!" mail-thread
I made a big mistake yesterday:

"Ugh, I just messed up drm-intel-next-queued big time.

I somehow rebased my work on top of drm-tip (I believe I did the rebase
in the wrong dir) and then after running a bunch of tests I
did a "dim push-branch drm-intel-next-queued" which pushed the
patches I intended to push rebased on top of drm-tip
pushing drm-tip to dinq :(

I'm so sorry about this.

I just checked my reflog and the last commit before me messing
up is commit d4de753526f4d99f541f1b6ed1d963005c09700c
("drm/i915: Unwind failure on pinning the gen7 ppgtt")"

To fix this I've just done a forced push resetting
drm-intel-next-queued to the mentioned d4de753526f4 commit.

I first checked no-one pushed anything on top of my mess,
but if you pushed anything to drm-intel-next-queued in the
last 24 hours, please double-check it is there.

Once more my apologies for this.

It happens, don't worry about it. Thanks for being open about it instead
of trying to brush it under the rug.

Thanks.

Did you pass -f to dim? I suspect drm-tip wouldn't pass the push checks
in dim without it. Perhaps we'll need to add more.

No I did not pass -f, I did wonder myself how the push managed to
proceed after my screw-up. Looking at how dim builds drm-tip, it seems
it starts with dinq and then merges in other branches, so a push
from a drm-tip based branch to dinq is a fast-forward (I think),
so dinq is special in this case.

Do you still have the git tree you've pushed wrongly and could publish it
somewhere? I'm suprised that dim push didn't catch this, we've added a few
more sanity checks last time around this happened. I'd have expected dim
to complain about all the patches lacking you're signed-off-by, since a
rebase would have changed a lot of patches to be committed by you.

I'm afraid I don't have that tree around anymore. What I did was I accidentally
rebased the 2 patches I wanted to push on top of drm-tip, so I pushed the
last drm-tip push (including the integration manifest) with my 2 patches on top.

So I pushed the latest unmodified state of drm-tip and none of the patches
in there were re-commited by me during the rebase.

Basically what I believe I pushed is a fast-forward from dinq to drm-tip +
the 2 patches I intended to push.

I even did a gitk before pushing to graphically check what I was pushing
(I always do this) and I saw my 2 patches on top of a remote branch, which
looked fine. What I did not notice it was the wrong remote and the wrong
branch. This is something which I've learned to also check now.

One check which I believe would have caught this is checking there are no
merge-commits in what is being pushed and require some commandline option
to override this for special cases.

Regards,

Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux