[Kde-pim] Git commit policy

[Andras Mantia]

On Friday, December 28, 2012 10:51:50 AM David Faure wrote:
> Sigh, it seems like the merge vs cherry-pick git discussion *has* to happen
> on every single mailing-list I'm subscribed to...

Sure, it happens if something is presented as a new policy. :) I partially 
followed the discussion on k-c-d and even there nothing was decided as 
mandatory afaik, and the discussion started years earlier. 

> 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.

The difference is that you must keep in mind to NOT commit the bugfix in master 
with the rest. So instead of "commit, commit, switch branch, cherry-pick, 
switch branch" you do "commit, switch branch, commit, switch branch, merge". 
I see a disruption in the workflow.

> > 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.

Usually you want the fix immediately in the branch you work on, no? I work on 
master, I do a fix there, so I want that fix to be there immeditately. That 
means switch to branch, commit, switch to master, merge. And that merge might 
bring unexpected things. I'm not sure it always does, but might bring in. 
Again, this is a disruption in your workflow, as you might need to focus on 
other issues, like conflict/merge fixes.

> > 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.

For me the history with merges are unreadable, but if others can read it, it 
is ok for me, as history is not that big an issue and annotation usually works 
anyway (and that is more important that a clean commit line).

> 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.

I'm not really buying this. As I said, a developer might just decide to not 
care about a branch. Then no policy will help (except a very strict one like 
Qt uses, when your code ends up in a release branch only after approval and 
automatic merges). And if the developer is confident enough that backporting is 
improtant, he will backport. 
 
> 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.

Ok, this is a more reasonable argument for the default "merge" policy.

> 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.

Unless that branch is master or a personal branch you work on. ;) BTW, don't 
read me wrong, I do not care only about master, but I care about having the 
bugfixes in branch as well.

> > 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.

That sounds much better, then a mandatory "always put in branch and merge" 
policy. I'll try to avoid cherry-pick if possible, to see how it works out. 
But don't expect for me to do every time. 

Andras

_______________________________________________
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/