* 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.