I'll revert those commits mentioned by Ian and tag 2.6.0 after.
On Fri, Apr 5, 2013 at 10:19 AM, Filip Maj <f...@adobe.com> wrote: > +1 to reverting. > > +1 to Shaz's point, slowly people will learn. For the record, if you want > to cherry-pick a commit from master into 2.6.x, you would do: > > $ git checkout master > $ git log --pretty=oneline --abbrev-commit HEAD^..HEAD # lets see the > last commit > abcd123 some commit message > $ git checkout 2.6.x > $ git cherry-pick abcd123 > > To be clear, this will create a *new* commit in 2.6.x, so don't be > surprised if the SHA changes after you cherry-pick it in. > > On 4/5/13 9:51 AM, "Shazron" <shaz...@gmail.com> wrote: > > >Let's revert, not rollback. I'm sure we expected some teething pains > >adjusting to the new scheme. > > > >On Friday, April 5, 2013, Ian Clelland wrote: > > > >> It looks like a number of commits intended for 2.7.0 were merged back > >>into > >> the 2.6.x branch > >> > >> My commits: > >> dbf631c: [CB-2305] Add spec tests for InAppBrowser.insertCSS and > >> InAppBrowser.executeScript APIs > >> 46e478f: [CB-2226] Add spec test for FileTransfer.abort error callback > >> da89eaa: [CB-1517] [CB-1518] Add spec test for gzip-encoded resources > >> 2003ff7: [CB-1517] Add an assertion that progress.total < > >>progress.loaded > >> > >> were all committed to master after the 2.6.x branch was split, but then > >> master was merged back into 2.6.x (acd1b96, Apr 2) > >> > >> There may be other commits in there that were merged accidentally; I > >> haven't looked at all of them yet. I think that any commits from master > >> which *should* be in 2.6.x should have been cherry-picked, rather than > >> merging master. > >> > >> From the iOS thread, I see that da89eaa was reverted, but the rest of > >>them > >> are still on the 2.6 branch. > >> > >> It's probably too late to just rewind the 2.6.x branch back to f6cbe2e > >> (rewriting public history and all that,) but should we revert the other > >> commits before we tag 2.6.0? > >> > >> Ian > >> > >
