[Kde-pim] Git commit policy

[Andras Mantia]

laurent Montel wrote:

> Le mercredi 26 décembre 2012 17:19:46 Andras Mantia a écrit :
>> Sérgio Martins wrote:
>> > Hi,
>> > 
>> > 
>> > We now have a page documenting kdepim git commit policy:
>> > http://community.kde.org/KDE_PIM/Development/GitCommitPolicy
>> > 
>> > It mostly talks about how we handle forward porting.
>> > 
>> > Nothing in this page is new, we've been doing and enforcing this
>> > workflow for months, I just wrote it down.
>> 
>> Sorry to ask, but was this discussed? It *is* new. I've been using master
>> as my main branch for years. That is where I fix bugs in first place and
>> sincerely I'm not really plan to change that.
> 
> You can fix in master and apply patch in 4.10
> => cd <kdepim-git-master> && git diff . ~/foo.diff && cd <kdepim-4.10> &&
> git apply ~/foo.diff
> 
> Not  really hard to do. And it's that you do when you use git cherry-pick
> -x but with git cherry-pick you create a new commit number => not easy to
> know if a specific commit is in all branch.

That is something one could try (and I will try to see how it fits in the 
workflow), but it has risks. 

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

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

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.

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/