mark carter wrote:
> Christian Thaeter wrote:
>>
>> Well you likely can't imagine how much kernel patches and repositories
>> are all around and will never be merged :) .. same with git itself, when
>> you look at the Mailinglist you see a lot of proprosals which are
>> abadoned, thats the way free software works when it is under control of
>> a benevolent dictator.
>>
> I'm not sure if any of you have seen the Google video where Linus talks
> about Git:
> http://www.youtube.com/watch?v=4XpnKHJAok8
> He expressed disappointment with all other forms of revision control
> systems that he reviewed after giving up on bitkeeper and starting git.
> He was asked what system he would use if he didn't have git (and
> bitkeeper), and he said that in that case he would probably just apply
> patches, like he did in his early days.
>
> I'm amazed! As you guys will no doubt be aware, I had created some
> patches for Ficl, and left cinelerra alone for some time. When I tried
> to apply the patches to a later version, there were quite a few
> conflicts. Backed up from my other (limited) experiences with revision
> control systems, I came to the conclusion that conflicts arise really
> fast. Mergability is a real problem. I guess Linus must be some kind of
> God.
It happens that there are no much changes in cinelerra, lucky for you.
Well, when I replaced the GC in cinelerra in my experimental branch,
which was a intrusive 10000+ Lines patch, syncing it with svn didn't
conflict much eihter. Cinelerra has so much code even 10k lines of code
barely scratch the surface.
Otherwise, git can't magically resolve conflicts, you *WILL* get them
too when things are edited concurently. The only any most important
difference for git is, that you can and should merge often. If all
involved people do that, then changes are propagated before they raise
conflicts and when conflicts happen they are small. If you don't do that
not even git would protect you from massive conflicts.
Merge often! Thats really easy and convinient in git. Some people
suggest test-merges, that is: Try a merge but undo it when there where
no conflicts, this keeps the history clean. For your private
(unpublished) branches you can use 'git rebase' too, which also gives a
clean history and keeps your work in sync with the main repository, be
careful that rebase 'rewrites' history. That means that you should never
ever use rebase if any other branch depend on it.
Christian
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
