No feature-branches in the mainline repositories

Andreas Pakulat apaku at gmx.de
Wed May 26 16:04:30 UTC 2010


On 26.05.10 16:14:14, David Nolden wrote:
> 2010/5/19 Andreas Pakulat <apaku at gmx.de>:
> > This wasn't really mentioned before so I'll do it now. Feature branches
> > should not be published into our mainline repositories, but into your
> > personal or a team clone of the repositories. The reason is so that our
> > mainlines only contain long-living branches like the stable release
> > branches. Such a feature branch may be merged later on, but just as well
> > it could happen that its being deleted, in which case people tracking
> > the branch will run into problems.
> 
> What exactly are those problems?

~/src/foo1>git pull
Your configuration specifies to rebase against the ref 'foo'
from the remote, but no such ref was fetched.

> When we start working on a different repository, people might track
> that one as well, and will run into exactly the same problems.

Not in the same way, they'd merge the remote branch into their local
master (or a local myfoobar branch). They wouldn't track the remote
branch.

This is a difference. The mainline repository should contain branches
you can checkout, track and regularly build. The topic-branches are
usually merged into a local checkout if you want to test out that
feature/change. In particular this is true for topic-branches that live
more than a day or so as in that case you want the changes from the
topic-branch with the rest of master together. Not some 8 weeks old
development stage of master (which the topic-branch was created from).

Andreas

-- 
You will be imprisoned for contributing your time and skill to a bank robbery.




More information about the KDevelop-devel mailing list