[FFmpeg-devel] libav commit f8c34f4b8d62afad3f63cf3d9617d73735bef8c1 (again)

[Mats Peterson]

On 03/16/2016 12:09 PM, Mats Peterson wrote:
> On 03/16/2016 11:46 AM, Michael Niedermayer wrote:
>> On Wed, Mar 16, 2016 at 10:06:56AM +0100, Mats Peterson wrote:
>>> Moritz Barsnick <barsnick at gmx.net> skrev: (16 mars 2016 09:59:00 CET)
>>>> On Wed, Mar 16, 2016 at 09:17:55 +0100, Mats Peterson wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>
>>>> Why are always 10+ mails quoted, when none of the context is of
>>>> interest? I'm tired of skipping all this stuff... I must find that mutt
>>>> patch again. (Mats, this isn't personally directed at you. Though you
>>>> "chains of thought" do extend "threads of mails" significantly.)
>>>>
>>>>> In any case, I don't see anything wrong with creating a patch that
>>>>> includes those changes, as long as I attribute the author properly.
>>>> It's
>>>>> no different from writing it myself, once again.
>>>>
>>>> You don't get the concept:
>>>> The "other upstream" or other branch has commits waiting to be merged:
>>>> ...
>>>> -A-
>>>>    -B-
>>>>      -C-
>>>>        -D-
>>>>          -E-
>>>>
>>>> You are asking to commit "something like C". In the best case, this
>>>> will become confusing when it comes time to merge C.
>>>>
>>>> In the worst case, it will bring conflicts when merging A, B, D and E,
>>>> making so much more manual work for the merger.
>>>>
>>>> The only acceptable thing to bring forward C is to merge exactly that
>>>> one commit ahead of time, if it's *really* important. But that requires
>>>> you to do the prework on that: branch ffmpeg master, merge *exactly*
>>>> that commit by cherry-picking (not rewrite something like it), commit
>>>> it to your branch, and provide that branch with this one merge-commit,
>>>> which can then be cherry-picked back into ffmpeg master.
>>>>
>>>> But why??????? What's so urgent? If you need that commit in order to
>>>> base your experiments on it, just go ahead and do the branching and
>>>> cherry-pick merging in your local clone, and work with that (and wait
>>>> to submit it here until that commit you're waiting for is in master,
>>>> and the dust around your own changes has settled - v23). Git makes
>>>> this stuff so easy for you.
>>>>
>>>> Moritz
>>>> _______________________________________________
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel at ffmpeg.org
>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> Using Git and "easy" in the same sentence is something I refrain
>>> from. But thanks for the in-depth information, Moritz.
>>
>> its easy
>> git cherry-pick -x f8c34f4b8d62afad3f63cf3d9617d73735bef8c1^
>> git cherry-pick -x f8c34f4b8d62afad3f63cf3d9617d73735bef8c1
>>
>> in this case work if your local git checkout knows of the commits
>> and you need f8c34f4b8d62afad3f63cf3d9617d73735bef8c1^ as it does some
>> whitespace messing the other alone would conflict a bit otherwise
>>
>> either way cherry picked and pushed
>>
>> [...]
>>
>
> Hm... OK. Thanks for the push, by the way. But I don't understand what
> you mean by "if your local git checkout knows of the commits".
>
> Mats
>
> _______________________________________________

You mean I should apply and commit them before "git cherry-pick"?

Mats