Good tip, thanks!

It seems like a rule that you learn one new thing about git every day :P

On 4/5/13 11:48 AM, "Michal Mocny" <mmo...@chromium.org> wrote:

>Fil,
>
>I'll add that you can add a -x to cherry-pick line so that git
>automatically inserts "(cherry picked from commit ...)" to the original
>commit message.
>
>-Michal
>
>
>On Fri, Apr 5, 2013 at 1:19 PM, 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
>> >>
>>
>>

Reply via email to