2011/4/22 Thomas Goirand <tho...@goirand.fr>: > On 04/22/2011 05:41 AM, Soren Hansen wrote: >> 2011/4/21 Thomas Goirand <tho...@goirand.fr>: >>> On 04/19/2011 05:55 AM, Soren Hansen wrote: >>>> 2011/4/18 Thomas Goirand <tho...@goirand.fr>: >>>>> Can't you just pull each individual patches that you feel ok with? Is >>>>> it simply not technically possible with bzr? >>>> Short answer: no. Longer answer: Of course it's possible to extract >>>> individual patches and apply them elsewhere, but it's tedious, manual >>>> and throws away history. We bzr users care deeply about history :) >>> I don't know bzr enough to be able to tell, but it seems like an area >>> of improvement. History, for me, is quite important. >>> With Git, it's really easy to get a bunch of patches, select the one we >>> want, and reject others. To compete with Git, Bzr *must* be able to do >>> that, and allowing rebase and merge of patches in order to keep a clean, >>> readable, patch history. >> Rebasing means ripping things out of their context and putting them [...] >> patches. > I wasn't discussing rebasing and hiding trials and errors or even > rebasing, but cherry-picking things in a branch that we see fits, and > are ready for a merge.
It may not be completely obvious on the surface, but those are essentially the same operation. Rebasing is besically cherry-picking a whole bunch of patches and applying them somewhere else. Or, if you prefer to see it that way, cherry-picking is essentially the process of rebasing a single commit. > You rejected a bunch of patches globally because only a tiny portion > of it aren't ok (like man pages stubs which I though we could work on > later), which I believe isn't very convenient. I thought we'd already been through this? > If I do the way you suggest, either I have to hold so many branches on > my local disk, which will soon give me headakes and are mistake prone, > or I have to stop working further on other patches until the previous > ones are accepted. Personally, I'm convinvced that having completely separate working directories for each feature I'm working on *reduces* my chances of mistakes. YMMV. > On 04/22/2011 06:36 AM, Soren Hansen wrote: >> All of these were done with a cold cache: >> >> It took 13.5 seconds to run "git diff". [...] >> Committing a one-line change with "bzr commit -m foo <filename>" took >> 1.5 seconds. > > IMHO, not really relevant. bzr intensively uses branches. Instead, try > to do: > > git checkout -b new-soren-branch > > This is pretty instant. Now do: > > bzr branch trunk new-soren-branch > > and wait for all files to copy ... You seem to have missed my final paragraph: >> I completely agree that bzr should have better mechanics for sharing >> working trees between different branches (the loom plugin does some of >> this, if you're interested). Apart for when I'm working on the Linux >> kernel, I've never really felt the need for it, but I understand that >> many people do. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
