Regarding bugfixes and branches and merging

[Andreas Pakulat]

On 19.05.10 13:32:11, Milian Wolff wrote:
> Andreas Pakulat, 19.05.2010:
> > 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:
> > > > 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.
> 
> No, it's not about that having a working KDevelop. It's about eating your own 
> Dogfood.

So? Wether you eat your dogfood right now or in 2-3 days doesn't matter.
Its not like we're doing a stable release once a week.

> And also: When I fix something, I was nagged by it and _want_ to use 
> it. That's why I fixed it after all.
> 
> I mean yesterday showed exactly why committing to stable is awkward:
> 
> - I implemented some changes in Snippets
> - Changed one thing that can be considered a bugfix
> - Introduced a few features on top of that
>  => the latter I did "blind" assuming my bugfix worked and only after merging 
> it finally I could see the "grand scheme".
> 
> If I'd done it all in master and only put the odd bugfix into 1.0 it would have 
> been much nicer workflow for me.
> 
> I mean what if it would have been more than one bugfix I discovered? If I'd 
> have merged everytime I could end up with lots of these merge commits...

Thats the point where you should edit your history before pushing.
Nobody stops you from doing this:

commit 1 - feature-commit for x
commit 2 - bugfix a (found during implementing x)
commit 3 - feature-commit for x

Now, you're done and want to publish, but the bugfix should be in 1.0, so
you do:

git checkout 1.0
git cherry-pick 2
git checkout master
git rebase -i HEAD~3, remove the bugfix from the list. If you then get
                      conflicts on the later commits fix them and continue
                      the rebase
git merge 1.0
git push origin master 1.0

With more than one bugfix you'd do the cherry-pick multiple times and
then remove them all from the interactive-rebase list.

Yes, thats more steps than just stopping at the cherry-pick. If everybody
is concerned about the time this consumes, then I suggest we don't merge
and only cherry-pick and then everybody will again be responsible for
taking care of putting bugfixes into the stable branch.

One more thing: Nobody stops you from merging the stable branch into your
feature branch.

Anyway, this is getting annoying to me and I'll just stop discussing it and
do whatever I like.

Andreas

-- 
You are standing on my toes.