Regarding bugfixes and branches and merging

[Andreas Pakulat]

On 18.05.10 21:34:40, Niko Sams wrote:
> On Tue, May 18, 2010 at 21:14, Andreas Pakulat <apaku at gmx.de> wrote:
> > Hi,
> >
> > ok, after about 1.5 weeks its pretty obvious that everybody wants his
> > fixes asap in master and at the same time nobody wants to spend time on
> > merging other people's fixes into master (which I totally understand).
> >
> > Hence I hereby suggest that everybody who has a bugfix to commit thats
> > applicable to 1.0 commits it to the 1.0 branch and then does:
> > git checkout master
> > git merge 1.0
> > git push origin master 1.0
> hmm... I don't know.
> that would cause lots of merge commits and that's not the best for
> master history.

Well, master would be mostly merge-commits anyway in the long run.

> If we go the immideately-merge-every-commit route, cherry-picking into
> 1.0 would be a better choice imho.

Except that with cherry-picking there's not connection between the
commits in git and its not possible to find out wether a given fix is in
1.0 or not. This is much easier when doing merging as you can easily see
all branches/tags/parents of the commit and instantly see that its in
master and 1.0

> But I still like the current state of not having to care about merging.

Yeah me too, but apparently others want the fixes instantly in master so
they have them in their kdevelop build. Frankly I don't really
understand that its so important given the fixes that were committed so
far. Its not like any of them stopped you from using kdevelop (IIRC),
except the fix from Andras yesterday.

Andreas

-- 
You have an unusual magnetic personality.  Don't walk too close to
metal objects which are not fastened down.