Am 16.02.2012 20:00, schrieb Andrew: > 16.02.2012 20:46, KP Kirchdoerfer пишет: >> Am 16.02.2012 19:00, schrieb Andrew: >>> 16.02.2012 19:54, KP Kirchdoerfer пишет: >>>> Hi Andrew; hi all >>>> >>>> just to understand how we use git. >>>> >>>> I saw that Andrew merged next with next-experimental. >>>> So will there be two "next" branches in the near future, or will >>>> one(next-experimental) replace the other(next)? And if so shouldn't we >>>> remove the old one, just one get not confused? >>>> >>>> kp >>>> >>> Merge operation is just to add all commits from one branch (or from >>> branch till some tag/commit) to another branch. Branch structure in that >>> case isn't modified, this is just adding changes from one branch to another. >> Ok, but how do we decide which one is used as "main" branch for >> developing the next version? > 'Next' of course. Today or tomorrow I'll finish all changes (now I > working on ipset) and merge all into 'next'. Maybe I'll update kernel too.
But you changed next into next-experimental today? And worked on next-experimental, as I did. So you will merge next-experimental back into "next" today or tomorrow? And use the work of next-experimental as base to update kernel from 3.24 to 3.2.6?? >> Or is it just my decision to remove remote tracking of branch "next" >> locally, if _I decide, that next-experimental_ is the way I'd like to go >> with? > Right. IMHO "Wrong" - if I do no locally track "next" any longer, I'll be working on the wrong branch IMHO. >I think that 'next' branch now may have 'alpha' status - enough > stable for building and testing, and main development will be into it; > but experimental features that may break building of 'next' branch and > that requires cooperative work of some peoples should be in > 'next-experimental'. Personal experiments may be done in local branches, > that are merged with 'next'/'next-experimental', and changes from them > may be merged completely or partial (via git cherrypick for ex.) to > 'next'/'next-experimental' ok. >> Building "new branches is cheap", tracking remote branches is easy - >> maybe I'm just too afraid about merging? > Maybe. GIT is versioning system that is based on patch mechanism, so > there is no difference in resource consumption between usual commit and > commit to new branch; also unused branches can be easily destroyed - all > commits that weren't merged in otner branches in that case will be lost, > but merged commits were remain on corresponding places. I see I'll have to read some more about git and esp merging :) kp ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
