On Tue, Oct 23, 2007 at 12:46:57AM -0400, Shawn O. Pearce wrote: > By merging only individual topics forked from master into next you > can merge those individual topics into master at different points > in time. For example db/fetch-pack has been in next for many weeks > and hasn't yet merged into master, yet jc/am-quiet was forked after > db/fetch-pack started and has already merged into master. > > Your way would make jc/am-quiet wait until db/fetch-pack was ready. > That's a big risk in the sense that your tree is "blocked" and even > simple changes are held up by ones that suddenly became a lot more > complex then you originally thought they were going to be. Yes, true. Alternatively, what I've been doing is that if I wasn't sure that a particular topic was ready to go to 'master' very shortly after it went into 'next', I would never let it go into 'next', but rather keep it in 'pu' (which is OK, because pu is constantly getting rewound). But I guess the downside of that is you might get fewer testers for the code, because fewer people are probably tracking and testing 'pu' as compared to 'next'. Right? - Ted - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
