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

[Daniel Vetter <daniel@ffwll.ch>]

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