Regarding bugfixes and branches and merging

[Niko Sams]

On Wed, May 19, 2010 at 14:44, Andreas Pakulat <apaku at gmx.de> wrote:
> 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.
>
Have patience with us - most of us are new to git :D
Especially advanced workflows like the one you described above have do
be learnt.

And I think it's important that we agree on something - if everyone
works differently
mergeing will be a mess.

Niko