David Woodhouse <dw...@infradead.org> writes: > 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.
Strawman alert: we don't *enforce* rebase. We leave it to the maintainer's discretion. Nothing stops a maintainer (or a chain of them) from accepting pull requests. But for better or worse, most maintainers rebase most of the time. When they do, they add their S-o-B to every patch, which provides a measure of accountability. I acknowledge your points are worth considering, even though you exaggerated for effect :)