On 03/08/16 17:23, David Woodhouse wrote: > On Tue, 2016-03-08 at 14:44 +0100, Laszlo Ersek wrote: >> >> Using git is one thing, designing a workflow is another thing. Many >> workflows exist. Some of them are not exclusively merge based (QEMU, >> various subsystems of Linux), where sub-maintainers rebase and >> occasionally rework patches that they queue for their next pull >> request. > > Ah, right. > > This "break your history by rebasing" workflow is so utterly wrong that > it didn't actually occur to me that it might have been *mandated*. I > assumed it was just a mistake by people who were not really familiar > with the tools and how to use them correctly.
Here again I can only point to people who I consider my betters -- are you suggesting that the QEMU workflow and the Linux workflow are utterly wrong? As I said, QEMU sub-maintainers and (some) Linux sub-maintainers keep *queues* of patches. Unstable branches with patches they apply and rebase. Are they all mistaken? > I thought I might need to overcome some resistance from those who can't > drag themselves out of the 20th century mindset of version control with > purely linear history, and needed to be shown the *reasons* why we > should actually do things properly. But I didn't expect there'd be a > mandate to do it wrong. I don't recall any mandate. I recall looking for examples and finding QEMU and Linux real quick. Their lowest levels of patch flow don't differ from ours; individual contributors practically never send pull requests. They send patches. > Do you have a reason to believe that there *is* such a mandate, rather > than a simple error? If so, I'll go and apply the cluebat there in a > more targeted fashion :) I think you should demonstrate one of the following: - Our (well, "my") interpretation of the lowest levels of patch flow in QEMU and Linux is wrong. - Or, QEMU and Linux sub-maintainers are mistaken, and it's our fault to have followed their example. Should we invite some of these maintainers to this discussion? Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
