Hi Soren,
On 04/22/2011 08:17 PM, Soren Hansen wrote:
>> 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.
In Git, when we do "git cherry-pick -x <sha-sum>" it takes a patch from
a branch, and put it in another one. That is what I meant. I don't see
how this can be called rebasing. Rebasing is taking patches, and putting
them on top of a branch, right? In my case, before you told me I should
not, I totally rewrote all patches, based on a diff -u -r, to make them
easy to pickup from.
>> 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?
Well, I agreed to work the way you want, because I think that's the
least I can do if you make the effort of reviewing my changes. That
doesn't mean I think it's convenient or the best way to go! :)
Can we agree to not agree? :)
>> 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.
That's not what I'm saying. I'm saying that, because of your workflow, I
need to use so many branches. If you were cherry-picking things that you
agreed, taking them *on a single branch*, that would be less error prone
for me than having to deal with so many branches. This has nothing to do
with the storage method (eg: "physical" separate directories in bzr,
which really, I don't mind (apart when projects are growing and bzr
branch starts to become an issue)).
>> 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.
I didn't miss it. My point is that bzr is extensively using branching,
so I think that doing a benchmark of any other thing isn't relevant. I
don't really care if a commit takes 15.8 or 16.3 seconds... Even
comparing the branching of Git and the one of bzr isn't helping, because
with Git, you'd do one branch once and for all, and work on it, then ask
someone to merge it or cherry-pick few patches. While with the workflow
we are using with bzr, we'd be doing branching for each single patch we
need to give for review. So, we are actually using quite a lot an
expensive operation.
Also, the linux kernel shouldn't be the only example, there are other
projects that are big (firefox, openoffice, etc) and these wouldn't be
manageable with bzr branching system. Maybe one day, Openstack will grow
too.
> Of course I can't. I'm objecting to the fact that certain conventions
> among users of certain tools encourage moving patches (not code, but
> patches to code. Very different things.)
Call me stupid, but ... can you please explain what's in the brackets? I
really don't get it when you are saying "git is a patch management
system and not a VCS", or when you say "not code, but patches to code".
Why is bzr different? In what way, new code stored in a patch isn't new
code?
> The problem is that the tools leave *no*
> way to tell if the change has been cherry-picked and taken out of its
> natural context or if it's in the exact place where I wrote it and
> tested it. It's the revision control systems' responsibility to make
> this obvious, and once you accept the concept of rebasing, you're
> instructing your revision control system to lie.
No. You might know it, I don't know. But with "git cherry-pick -x", it
does leave clues in the log:
zigo@GPLHost:buzig>_ ~/sources/bla$ git log
commit 2ebd1a7555463fe10d5de5cbe2e04469bef9fc47
Author: Jan-XXX <x...@xxx.net>
Date: Fri Apr 15 13:43:17 2011 +0200
Support for intermediate certificates for shared ssl.
(cherry picked from commit 5a7ec060fe769b41cf81ca08dcbf6db9e9bc2afa)
Topically, you'd do that a lot with Git, so that patches can go from one
branch to another. It is extremely useful when you are backporting
fixes, for example from a development to a stable branch, and that's one
of the reason why we try to keep history clean in Git.
This is the workflow I'm used to, and what I was expecting when using
bzr. The workflow you described to me, using multiple branches, doesn't
seem so convenient (I'll be using it only because you asked...).
I hope I made myself more clear than before and that you now got my
point! I'm not a so good English writer.
Anyway, I guess that all the above (eg: branches vs cherry-pick of
patches) is mostly a question of tastes. We can debate during hours, and
still not agree. But it seemed to me that there's a majority of people
in Openstack that are used to git and like the workflow I described. I'd
be happy if others would express themselves about it, so that we can
have a vague idea of what people think.
Thomas
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
