On Sun, 2012-03-25 at 12:09 +0200, Avi Kivity wrote: > Well I've been doing this ever since I moved to git. The motivation was > actually to make things easier for patch authors by allowing them to > work against a tree of all applied patches, while the update for the > next merge window is just a subset, with more fixes going into the merge > window even late in the cycle, and features being deferred to the next > one. I also fold fixes or reverts into their parent patches to improve > bisectability. > > I can switch to fast-forward-only in the future, but I'm afraid that > this particular tree is broken for good. The un-rebased > fast-forward-only source for this is kvm.git master, which I don't think > you want to pull. It will cause every kvm commit to appear twice and > confuse everyone. The problem is that it makes it very hard if not impossible to work with a combination of your tree & other trees (for example at some point I had to work on a merge of alex'tree, powerpc-next and pci-next). I don't see the problem with using the standard way and having sub-maintainers/developers.... Most of my sub-maintainers work on top of some upstream or they branch off my -next branch (which is known to never be rebased, so it's resync'ed as soon as Linux pulls it). Dealing with branches & merges in git is trivial and easier than dealing with the clashes caused by the rebases :-) One thing I do, is to also sometimes put out a powerpc-test branch that people know can and will be rebased, it's purely there if I want some folks to test a bunch of stuff but without basing their own work on top of it. And yes, there's a drawback vs. bisectability. You can still fold-in if you pickup patches from the list (vs pulling from sub-maintainers) as long as you haven't committed them to a "non-rebase" branch (ie, you can let things stage in a test branch for example for a couple of weeks to flush out those issues). Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
