qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] why restrict pull reqs to signed tags?


From: David Woodhouse
Subject: Re: [Qemu-devel] why restrict pull reqs to signed tags?
Date: Thu, 10 Mar 2016 08:21:50 +0000

On Wed, 2016-03-09 at 15:41 +0100, Laszlo Ersek wrote:
> According to your description, QEMU uses git improperly, so does
> libvirt, and the KVM (kernel) queue too.

Let's see...

Imagine I'm working on a new feature, and I submit a carefully tested
sequence of commits in a pull request.

Someone *rebases* my work onto a different point in history, which
introduces a bug.

The record now shows that I submitted something *broken*. Like
https://github.com/openssl/openssl/commit/963bb621 for example, which
is utterly hosed and broke the build for everyone except me. 

On that occasion, I was able to look back at what I *actually*
submitted and point out that it wasn't my fault. But sometimes the
breakage is more subtle. You end up looking back a few months later and
trying to work out why an esoteric corner case is failing. You might
ask me, and I'll say that I *distinctly* remember I thought about it,
and that I could have sworn I *had* tested it.... 

But again the record shows that what got merged has *never* worked.
That's no longer just a problem of embarrassment for the submitter, by
misrepresenting their work. That's now causing problems for the
*project*. Because if history had been represented *correctly*, with a
working commit and then a subsequent merge introducing the breakage,
then that is a *whole* lot easier to figure out.

Preserving accurate history is a large part of the reason we *have*
version control systems. And yes, if any of those projects you list are
deliberately throwing away history as a matter of course on non-trivial 
submissions, then I would say that they are using the tools improperly.

Of course, for simple patches it often makes no difference (well, apart
from the OpenSSL example I gave above). And for larger submissions it
doesn't *often* make a difference. But that's not the point. Sure, let
people apply their *discretion* about rebasing stuff, if you really
must — but a workflow which *enforces* a rebase, and *never* lets you
pull a complex submission as it *actually* happened, is quite wrong.


-- 
dwmw2

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]