24.06.2011 13:58, Erich Titl пишет: > Hi Andrew > > at 24.06.2011 11:56, Andrew wrote: >> 24.06.2011 09:17, Erich Titl пишет: >>> Andrew >>> >>> at 23.06.2011 16:02, Andrew wrote: >>>> 23.06.2011 16:18, Erich Titl пишет: >>>>> Hi Andrew >>>>> >>> ... >>> > ... > >> It seems like you already have added BuC repo, and now your local >> master is synchronized with remote, and top commit in log should be >> 907bb43. > The BuC repo was probably created by the pull. No, repos are created only by hand. > I always expected a branch like BuC4 there. > IMHO we should maintain main branch - master, which should be considered as evolutionary improvement of BuC (standard things like packages/libraries/compiler updating, non-global scripts modifications and so on), without revolutionary changes. Other branches should be created in next cases: 1) When some release is stabilized and future work on it will be just making bugfixes 2) When somebody will like to make heavy experimental modifications that shouldn't be added in main tree at least in development stage (for ex., rewriting toolchain makefiles and future modifications of package makefiles) 3) Similar cases when modifications from branch shouldn't be applied immediately into main branch or potentially should be moved into new repo after critical mass of incompatibility (for ex., after rewriting toolchain makefile and moving to plain source distribution if it will be in future). >> Now you may try to switch to experimental branch and do git rebase to >> current master. > mega@luna:~/leaf/devel/leaf> git checkout experimental > Switched to branch "experimental" > mega@luna:~/leaf/devel/leaf> git rebase master > Current branch experimental is up to date. > > As long as I stay in experimental everything appears to look as > expected. The only thing that puzzles me now is how to see the > differences between the branches. I understand that git diff shows the > differences between commits, but what about branches? I don't want to > merge blindly. > It also shows differences between branches :) > Committing tarballs makes the conflict resolution more difficult IMHO. > Do you think it is worth to keep work on 'leaf' untarred in the repository? > > cheers > > Erich Working on untarred sources are simplier, but it'll require buildtool modifications. Maybe it'll be done in BuC5 - with toolchain rewrite and other significant modifications. Also tarballs now are commited only with standard untouched versions from other sources - and on updating old tarball is removed, and new with new name is added. In any case, this should be a place of discussions in future, when we'll move to toolchain review.
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
