Fixes in Git (first in stable, then merge to master)

[Aurélien Gâteau]

Le 20/07/2011 11:52, Alex Fiestas a écrit :
> Hi there
> 
> Last few days I have been patching some pieces of our workspace here and 
> there, the first set of patches I did them directly into master which if 
> I remember correctly was against the policy.
> So, the second round of fixes I tried to do it the right way, which is:
> 1-Create the patch while using 4.7 (optional I guess)
> 2-Test the patch in 4.7
> 3-Commit the patch in 4.7
> 4-Checkout master branch
> 5-Merge 4.7 into master
> 
> In theory, this workflow should work (I like it dcvs-wise) but the 
> reality for me was:
> 1-A lot of conlicts
> 2-Conlicts on software I don't know about
> 3-Conflicts in .desktop translations
> 4-Something that should be almost instant, is not <at all>
> 
> The result of a merge of 4.7 in master can be observed in the attached 
> screenshot.
> 
> So, at this point I'm wondering if the policy is bad or (and this option 
> is the more plausible) I don't know how to use the tool.

What I have been doing recently to avoid cherry-picking is to create my
fixes in a separate work branch, then merge the branch in both 4.7 and
master branches. This way the commits do not have different commit ids.

Aurélien