All of lore.kernel.org
 help / color / mirror / Atom feed
* Forced push done to drm-intel-next-queued
@ 2018-12-25  8:04 Hans de Goede
  2018-12-27 14:42 ` Jani Nikula
  0 siblings, 1 reply; 6+ messages in thread
From: Hans de Goede @ 2018-12-25  8:04 UTC (permalink / raw)
  To: intel-gfx

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.

Regards,

Hans

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Forced push done to drm-intel-next-queued
  2018-12-25  8:04 Forced push done to drm-intel-next-queued Hans de Goede
@ 2018-12-27 14:42 ` Jani Nikula
  2018-12-27 15:24   ` Hans de Goede
  0 siblings, 1 reply; 6+ messages in thread
From: Jani Nikula @ 2018-12-27 14:42 UTC (permalink / raw)
  To: Hans de Goede, intel-gfx

On Tue, 25 Dec 2018, Hans de Goede <hdegoede@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.

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.

Anyway, checking against what I had on Friday, I think it all checks
out. It's of course possible something was pushed on top, but I doubt
it. Due to the timing, it was pretty quiet. So not much maintainer
support for you, but also not much harm done either.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Forced push done to drm-intel-next-queued
  2018-12-27 14:42 ` Jani Nikula
@ 2018-12-27 15:24   ` Hans de Goede
  2019-01-15  9:56     ` Daniel Vetter
  0 siblings, 1 reply; 6+ messages in thread
From: Hans de Goede @ 2018-12-27 15:24 UTC (permalink / raw)
  To: Jani Nikula, intel-gfx

Hi,

On 27-12-18 15:42, Jani Nikula wrote:
> On Tue, 25 Dec 2018, Hans de Goede <hdegoede@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.

> Anyway, checking against what I had on Friday, I think it all checks
> out. It's of course possible something was pushed on top, but I doubt
> it.

Great, thank you for double checking.

Regards,

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Forced push done to drm-intel-next-queued
  2018-12-27 15:24   ` Hans de Goede
@ 2019-01-15  9:56     ` Daniel Vetter
  2019-01-15 11:46       ` Hans de Goede
  0 siblings, 1 reply; 6+ messages in thread
From: Daniel Vetter @ 2019-01-15  9:56 UTC (permalink / raw)
  To: Hans de Goede; +Cc: intel-gfx

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@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.
-Daniel
> 
> > Anyway, checking against what I had on Friday, I think it all checks
> > out. It's of course possible something was pushed on top, but I doubt
> > it.
> 
> Great, thank you for double checking.
> 
> Regards,
> 
> Hans
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Forced push done to drm-intel-next-queued
  2019-01-15  9:56     ` Daniel Vetter
@ 2019-01-15 11:46       ` Hans de Goede
  2019-01-22  9:56         ` Daniel Vetter
  0 siblings, 1 reply; 6+ messages in thread
From: Hans de Goede @ 2019-01-15 11:46 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Forced push done to drm-intel-next-queued
  2019-01-15 11:46       ` Hans de Goede
@ 2019-01-22  9:56         ` Daniel Vetter
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Vetter @ 2019-01-22  9:56 UTC (permalink / raw)
  To: Hans de Goede; +Cc: intel-gfx

On Tue, Jan 15, 2019 at 12:46:50PM +0100, Hans de Goede wrote:
> 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@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.

Hm right we filter for committer, so if you're not the one who pushed the
very latest drm-tip then all the merge commits in there (and the
integration manifest) won't trigger and checks of dim 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.

The problem with that is that you train maintainers (who routinely need to
push merge commits, that's their job) to ignore dim warnings. Which also
is not great. Jani&me had a few discussions and failed starts (had to back
a few changes out of dim again), not sure what exactly we could check more
now :-(

I guess mea culpa, perhaps we'll come up with a better idea in the future.

Thanks anyway for helping with debugging this tooling issue.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-01-22  9:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-25  8:04 Forced push done to drm-intel-next-queued Hans de Goede
2018-12-27 14:42 ` Jani Nikula
2018-12-27 15:24   ` Hans de Goede
2019-01-15  9:56     ` Daniel Vetter
2019-01-15 11:46       ` Hans de Goede
2019-01-22  9:56         ` Daniel Vetter

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.