[Intel-gfx] Forced push done to drm-intel-next-queued

[Hans de Goede]

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 at redhat.com> 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