[Kde-pim] Git commit policy

[David Faure]

Sigh, it seems like the merge vs cherry-pick git discussion *has* to happen on 
every single mailing-list I'm subscribed to...

On Thursday 27 December 2012 12:17:38 Andras Mantia wrote:
> One problem could be that the bugfix is discovered while you are developing
> a new feature in master. It is ok to put the bugfix in a separate commit,
> but many times the feature is not finished yet, so this complicates the
> diffing and backporting. With cherry-pick, you could just cherry pick the
> bugfix commit.

I don't see the difference. You make all your commits in master locally (with a 
separate commit for the bugfix, as you describe), then cherry-pick that commit 
locally to your stable branch [this can be done when using git-new-workdir, 
they commits from the two local checkouts are shared; otherwise use a manual 
patch file], commit to stable, merge, commit the rest in master.

> In the same case it could also happen that you put the fix in branch, merge
> to master, and the merge brings some changes back to master you don't want
> at that point, disrupting your workflow.

I don't really believe this. You decide when to merge or pull, so there is no 
unwanted disruption of your workflow.

> It also has the risk of multiple merge commits in master, because we are
> usually not perfect and sometimes a fix needs another fix.;) So it would be
> push to branch, merge, push to branch, merge.

Which is perfectly fine.

> To be honest, I'm challenging the argument of "not easy to
>  know if a specific commit is in all branch." How many times do you
> look/check if a specific commit is in all branches?

I agree, this isn't the main reason for using git merge, it's just an added 
benefit.

Here are the main reasons for using git merge:

1) it ensures that no bugfix is forgotten. How many times, when using svn, did 
we end up with "oops, I forgot to backport/forwardport this". Or needing 
someone with a sharp eye (hi Allen), telling people "did you forget to 
backport this?". Git merge ensures that we never forget to apply the fix to all 
necessary branches, as long as the bugfix is committed to the "oldest branch".
I would never manage kdelibs' current 4 branches (4.9, 4.10, master, 
frameworks) without using git merge.

2) I read this argument recently, which IMHO is the best one, in an opensource 
world of people with different opinions: if everyone uses cherry-pick and one 
guy uses git merge, you end up with 99% of duplicated commits in the history.
If everyone uses git merge and one guy uses cherry-pick, you end up with 1% of 
duplicated commits in the history. So clearly the recommended default should 
be git merge.

> It is up to the
> developer to put his commits in the right branches where it belongs to. Such
> a policy will not help, a developer can still just put the bugfix in master
> and don't care about the branch. 

This can happen in all cases (merge policy or cherry-pick policy), so it's 
unrelated to the issue at hand.

On the other hand, git merge makes it possible for people who do only bugfixing 
and no features (e.g. myself) to only work on a single branch (stable), and 
they can be sure the commits will be merged. It's better to merge yourself (to 
handle conflicts), but at least if you "only care about one branch", the 
bugfixes won't be forgotten.

> If he cares about the branch, cherry-pick
> puts the fix in the branch just as well. And if the description is detailed
> (not just something like "fix a bug"), and -x is used, it is clear the fix
> was applied there.

Yes, this is the workaround for cleaning up after people who "only care about 
master". It doesn't mean it has to be the recommended way :)

> What I did in many cases, especially with larger changes was to work on
> master, and then after it proved to be good on master (that includes some
> 3rd party testing), backport the features/bugfixes. When backporting I build
> and if time permitted tested manually the branch. The benefit of this was
> that I didn't have to constatly switch between the branches, but could do
> it as separate tasks.

This isn't the most common case for bugfixing, I think you'll agree. But when 
it happens, then yes, there's no other solution than "applying the cherry-pick 
workaround". And you know what? This is perfectly fine. It's the 1% of my 
argument number 2 above. I don't believe the policy should forbid this to the 
point of making the perpretator have to fix a bug in glib or something :)
The recommended solution should be "fix in stable, merge in master", but in 
special cases like "not enough confidence in a bugfix for immediate backport", a 
cherry-pick won't kill anything. It will just lead to a duplicated commit in 
the history, we'll survive.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/