On 03/25/2012 10:51 PM, Benjamin Herrenschmidt wrote: > 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) Say a fix comes in which needs to be mainlined during -rc. So I put it in some other branch, to be sent off to Linus in a few days after maturing a little. Meanwhile developers see an incomplete tree, since that patch is not in it. Once Linus pulls, I can merge it back (or even before, if I'm reasonably certain it's not going to change), but it leaves a history of unneeded merges. Or we can do throwaway merges like tip.git. > . 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). Right, we'll probably do something along these lines. -- error compiling committee.c: too many arguments to function -- 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
