Dicebot, el 10 de December a las 14:01 me escribiste: > On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote: > >I which case, updating with master will be counter productive. > >Thanks for the heads up. I will just have to rely on the devs to > >cherry-pick what was not originally included in the branch. > > cherry-picking is discouraged in that scenario as it will complicate > merging 2.065 branch back into master after release. rebase sounds > like best fit.
I don't understand. Rebasing the release branch on top of master shouldn't be an option, as it means you are taking all the changes to master and put them in the release branch. That's just using master as a release branch. The other way around would be crazy. What problems do you see merging cherry-picked stuff back into master? IIRC git should be smart enough to recognize duplicated commits and ignore them, at least if you merge often. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer para después me deje trabajar en PHP con este .cab