[Kde-pim] Git commit policy

[David Faure]

> On Friday, December 28, 2012 10:51:50 AM David Faure wrote:
> > 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.

No no, as long as you don't push your commits, you could very well do

commit, commit, commit, all done, but don't push yet. Switch branch, cherry-
pick [or apply patches] from local master, commit, push, back to master, 
delete local commits which you picked into stable, merge.
If you want to not disrupt your workflow, this is definitely a solution, 
although it requires some more steps.

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

See above; as long as you don't push, you could very well keep working on 
master with your undeleted-yet bugfix, which will come back later via the 
merge.

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

You're confusing too issues. The guy who doesn't care (which as I said, is 
unrelated to the solution chosen here), and the guy who's just forgetful (e.g. 
me). With svn I often forgot to forwardport/backport; not because I didn't 
care, but because I would forget. This is quite different: it means I care 
enough to "commit to the right branch", with git, but after that I don't have 
to remember to forwardport, it will happen automatically.

For people working on stable, it's really perfect: I can just commit all 
bugfixes in stable, and know that they'll all get merged into master, whether 
by me or someone else, but for sure never forgotten.

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

Sure, I know that.
Sorry, the "you" in my paragraph was the impersonal you (=anyone), not you 
Andras.

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

I'll let the actual PIM developers decide if that's good enough - but for me 
it is.

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