On Mon, Jan 31, 2011 at 2:13 AM, Gordon Woodhull <gordon@woodhull.com> 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