Jaime Melis <jme...@opennebula.org> writes: >> Hmm, writing the question seems to gives my answer, it looks like the >> cherry-picking of master commits on the one-<version> branches are the >> reasons of the merge conflicts. >> > > Yes... that's the way we usually do it: by cherry picking the commits.
Ok, I'll broke everything to rebase on master then. > Unfortunately we don't think there's an easier way. Personally, I prefer to use DaggyFix[1][2] over cherry-picking. This requires to base the commits on the oldest supported release and then merge them everywhere needed, which can be seen as a lot of work, but not that much different from doing cherry-picking ;-) I think DaggyFix is more GIT friendly and respect the context as explain in an article I just found[3]. For example, here is the GIT graph to apply a foo-bar patch (issue #42): o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-M₃ <- master \ \ \ \ / \ \ \ o-o-o-o-M₂ / <- prod/4/master (integration branch for version 4) \ \ \ / / \ \ \ o-o---+ <- prod/3/42-foo-bar (short living branch) \ \ \ / \ \ \ o-o-o-o-M₁ <- prod/3/master (integration branch for version 3) \ \ \ o-o-o-o-o-o-o-M₀ <- prod/2/master (integration branch for version 2) \ \ / \ o-o-o-o <- prod/2/41-fix-something \ o-o-o-o-o-o <- prod/1/master (integration branch for version 1) in this example: - version 1 is not supported anymore - version 2 is supported but not concerned by #42: foo-bar A temporary branch is created based on version 3 named prod/3/42-foo-bar and the commits are done here. I use do to prefix my branch names by the name of the release branch it first apply to, it help to sort them when doing “git branch” ;-) Then, this 42/foo-bar branch is merge back into version 3 integration branch (commit M₁), to prepare a new release 3.X. This 42/foo-bar branch is merge into version 4 integration branch (commit M₂) if it apply to it like in my example. Finally, this 42/foo-bar branch is merge into the main development branch (commit M₃) if it apply to it like in my example. This is based on the “successful Git branching model[4]” I extended with the packaging branches. I hope it will help you, it took me time to find some kind of best practice I agree with, like “Is it better to rebase or merge?[5]”. Regards. Footnotes: [1] by mercurial http://mercurial.selenic.com/wiki/DaggyFixes [2] by monotone http://wiki.monotone.ca/DaggyFixes/ [3] https://queue.acm.org/detail.cfm?id=1595636 [4] http://nvie.com/posts/a-successful-git-branching-model/ [5] http://www.randyfay.com/node/91 -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF
signature.asc
Description: PGP signature
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org