Open Stack

2011/4/22 Thomas Goirand <thomas at goirand.fr>:
> On 04/22/2011 05:41 AM, Soren Hansen wrote:
>> 2011/4/21 Thomas Goirand <thomas at goirand.fr>:
>>> On 04/19/2011 05:55 AM, Soren Hansen wrote:
>>>> 2011/4/18 Thomas Goirand <thomas at 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/