Every commit in 4.4 is from 4.4-forward, that's why we create 4.4-forward I think?
--Sheng On Mon, Jul 28, 2014 at 9:44 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 >
