Then what about all fixes that went into 4.4-forward if they don't get picked up that contribution will not be used at all.
Sent from my iPhone > On Jul 28, 2014, at 9:45 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: > > I don't like the idea. release (candidates) are on 4.4 > > On Tue, Jul 29, 2014 at 5:43 AM, Animesh Chaturvedi > <animesh.chaturv...@citrix.com> wrote: >> Yes that's how I did for 4.2 and 4.3 >> >> Sent from my iPhone >> >> On Jul 28, 2014, at 6:28 PM, "Sheng Yang" <sh...@yasker.org> wrote: >> >> Daan, >> >> 4.4-forward should contain all the commits for 4.4. So 4.4-forward itself >> should be able to make as 4.4, without merge back to 4.4? >> >> That's what we want to have a 4.4-forward for 4.4. future release. It's >> superset of current 4.4 branch. >> >> Well, probably result in a force-overwrite. But I guess how we did it in >> 4.3? Animesh? >> >> --Sheng >> >> >> On Mon, Jul 28, 2014 at 2:36 AM, Daan Hoogland <daan.hoogl...@gmail.com> >> wrote: >>> >>> H, >>> >>> I tried merging 4.4-forward back into 4.4. This leaves us with a grand >>> big conflict. I have calculated that the number of not cherry-picked >>> not reverted commits is 185. I will start cherry-picking them at >>> moments $dayjob allows. and then send a mail again. >>> >>> don't forget to read up on the proces git-flow is based upon. We will >>> need to start working with a branch-merge per fix instead cherry-picks >>> in the very near future. >>> >>> kind regards, >>> -- >>> Daan > > > > -- > Daan
