On Thu, Dec 9, 2010 at 8:32 PM, David S. Ahern <daah...@cisco.com> wrote: > > > On 12/09/10 06:05, Gerd Hoffmann wrote: >> >> Hi, >> >>> New features developed for the kernel are done in a separate git trees. >>> When a feature is ready for inclusion into the main kernel tree, a pull >>> request is sent. That workflow maintains a complete change history for >>> the feature. Take performance events for example: you can go into Linus' >>> git tree and see the complete history of changes. There's no reason the >>> same methodology cannot be done for qemu. >> >> It is done for qemu, pci and block are maintained that way for example. >> The key difference is that the patches which are accepted into the >> subsystem branches and then are pulled go through a full review @ >> qemu-devel before. > > Yes, I know I've been following qemu and kvm for 3 years now. And there > is no reason the same process cannot be done for usb as a subsystem or > ehci as a feature branch. Jan already has that started. > > I realize this is most likely a moot point given that xhci appears > better suited for virtualization than ehci, nonetheless it bugs me that > you are not wanting to take the time to maintain the code change and > sign-off histories.
The problem with that approach is that the introduction of new features becomes a single commit. From bisectability point of view this is bad, especially with big features. So I'm much more interested in having a lot of small commits than huge commits or merges, even at the expense of loss of some history information. If we can have both, for example by doing some kind of partial pull, that would be the best of both. I may as well be ignorant about some great git features.
