+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
>>
