On Tue, 12 Feb 2008, David Miller wrote: > > But as soon as I've applied any patches to my tree I've "pushed out". > So this scheme doesn't work for me. The first thing I do when I have > changes to apply is clone a tree locally and on master.kernel.org, > then I apply that first patch locally and push it out to master. I actually suggest you literally delay your push-out. I don't generally delay things by a lot, but I tend to try to at least do a compile in between pushing out - and even if I've pulled something in between the thing that broke, I'll just "git reset --hard" to a working state if something broke, and just re-pull instead of even trying to rebase or anything like that. (IOW, I often find it much easier to just start over and re-do than actually doing a rebase). I don't do it all the time, by any means, but there's really no huge reason to push out all the time. And that's doubly true for subsystem maintainers. Quite often, the right thing to do is to only push out when you are ready to do the "please pull" message. > What would be really cool is if you could do the rebase thing, push > that to a remote tree you were already pushing into and others could > pull from that and all the right things happen. It would also be really cool if Claudia Schiffer had decided that hiding under my desk is a good idea. IOW, you really haven't though that through. That is how TLA and darcs worked, and it's a total disaster. Trust me, you don't know how good you have it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
