Andreas Dilger wrote:
> The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
> which patches he wants to accept as easily as importing them at the time
> he reads each email. It basically assumes that he wants everything that
> is in the repository he is pulling from.
Yes and no. 'bk pull' does indeed make the presumption that Linus will
like or dislike the entire patchset being pulled. That's why one wants
to separate different types of changes into different BK trees. For
example you might have a BK clone with just ext2 fixes, then a BK clone
off of your ext2-fixes tree which contains your ext2 resize work. Or,
if you wanted those separate and not parent-child, you could clone both
ext2-fixes and ext2-resize trees off of Linus's standard tree.
But I disagree a bit. Basically, if you organize the trees from which
Linus would do a 'bk pull' then he can easily (a) 'bk unpull' if he
dislikes everything, and (b) easily inspect each changeset.
I personally plan on sending Linus GNU patches simply for his review, as
I did with the recent swap_device cleanup patch, as well as giving him a
location for doing the 'bk pull'. In that specific case, there was a
tree http://gkernel.bkbits.net/vm-2.5 which contained nothing but that
one change.
Used in this sense, 'bk pull' is really the primary merging tool, and
e-mail is simply a reminder to Linus that he should do a pull.
Jeff
-- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:00:30 EST