On Sun, Jan 04, 2009 at 06:10:06PM +0100, Patrick Winnertz wrote: > Am Sonntag 04 Januar 2009 17:48:56 schrieb Oswald Buddenhagen: > > fwiw, the suggested backporting workflow is quite a nightmare with git, > > as all the merging goodies work only with forwardporting. > > I know but having many many branches with patches inside is also a > nightmare.. > in order to have a overview. > to alleviate that one could have a "collector" branch to which all halfways ready feature branches (and master) are merged. but from that branch no-one would ever merge; it would be a constant dead end. unless it was decided that all branches are ready at the same time, in which case it *could* be merged.
> > instead, you need to develop on master (the conventional name for > > the trunk), branch for stabilization of each release, do *all* > > bugfixing in the current stable branch and merge it back into master > > each time fixes have been applied. > > A improvement of the situation atm would be to make master the stable > branch and creating one testing branch which is based on master, > wouldn't it? > you can have just one testing branch from which you constantly merge fixes to master and to which you merge master each time you want all new features for a new stabilization phase. but note the *all*. merging in git is always a wholesale thing (well, in fact, you can stop the merge before the current head of a branch, but you cannot omit changes in between). > > major new features have to be developed on branches of master, so > > they can be merged back into master. everything else results in use > > of cherry-pick, > > cherry-pick was the tool I wanted to use. > that way you give up almost all of the power of git, including showing cool merge history graphs. you could have the same by creating local svn repositories for disconnected development and doing the merging via patches to a conventional central repository. git just doesn't work well for the freebsd model. it is optimized for the linux model, and of that only the main line (the stable series are a little cherry-pick sucker) - for obvious reasons. _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel