Re: [boost] RE process (prospective from a retired FreeBSD committer)...

Subject: Re: [boost] RE process (prospective from a retired FreeBSD committer)...
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-30 13:32:09

On Mon, Jan 31, 2011 at 2:13 AM, Gordon Woodhull <gordon_at_[hidden]> wrote:
>
> On Jan 30, 2011, at 12:24 PM, Dean Michael Berris wrote:
>> Why would it be more work? I don't see why you think it would be more
>> work. If the server choices are github, gitorious, sourceforge git
>> repos, or your own publicly accessible server, who does it have to be
>> more work for? And to that point, if pulling from multiple sources is
>> just one command, why would that even be more work?
>
> Aha. Â I thought there must be some misunderstanding here. Â Distributed repositories shouldn't mean that everyone has to keep track of dozens of servers.
>
> Dean, or other Git advocates, can you also answer Volodya's other big concern?
>

Let me try...

> On Jan 30, 2011, at 10:06 AM, Vladimir Prus wrote:
>> Suppose you have library X with 200 new changes. For next release, it is
>> necessary to include one of those changes. How do you do that? With
>> current release process, it's a single command (obviously, run by a
>> single person).
>>

Simple: if these 200 changes are in a STABLE branch, then all those
are pulled by the release managers. If only one of those 200 changes
are to be released by the library developer, then he shouldn't have
moved 200 changes into the STABLE branch -- and the release managers
can just choose to ignore the 200 changes and just pick the one that
"fixes" the issue for the release and be done with it. I don't see
*why* this is a big problem.

Am I missing something?

>>> And regardless, SVN has all the same issues w.r.t. picking individual
>>> changes, doesn't it?
>>
>> No. When you merge a single revision from branch A to branch B, SVN
>> records accurate information about this merge. When you do 'git cherry-pick',
>> git does not record any information whatsoever and is fundementally unable
>> to record it.
>

In git, individual changes have two important things that come with
it: the patch/changes, and the parent from which these changes apply.
If you want to cherry-pick a commit from one branch to another, 'git
cherry-pick' is *exactly* the command you use -- and you can even edit
the message that gets committed when you do this cherry picking.

Now, let's say you finally merge the changes from the whole branch
from which you cherry-picked a commit into the branch that has this
cherry-picked change already applied, git is actually smart enough to
see that the change is already there and would not have to apply it
again -- and since the original parent from the cherry-picked commit
is recording in the commit for the cherry-pick, that's all transparent
for you. Heck in git, even if you have the same change/patch applied
in 100 different branches and try to merge them all into a single
branch, it's smart enough to see that "oh, these patches look alike so
I don't really need to apply them over each other and just pick one".
This is what dela-merging and delta-fingerprints do that is *not*
there in Subversion.

http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html

http://progit.org/book/ch5-3.html

-- 
Dean Michael Berris
about.me/deanberris