Re: git+patch workflow [WAS: bundled intl stuff necessary]

[Oswald Buddenhagen <ossi kde org>]

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.