[FFmpeg-devel] libav commit f8c34f4b8d62afad3f63cf3d9617d73735bef8c1 (again)

Mats Peterson matsp888 at yahoo.com
Wed Mar 16 12:38:01 CET 2016


On 03/16/2016 12:32 PM, Michael Niedermayer wrote:
> On Wed, Mar 16, 2016 at 12:10:40PM +0100, Mats Peterson wrote:
>> 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"?
>
> no, find the git url of the branch where the commits are then
> git fetch it (there are other options but that works)
>
> in this example:
> git fetch https://github.com/libav/libav.git
> git cherry-pick -x f8c34f4b8d62afad3f63cf3d9617d73735bef8c1^
> git cherry-pick -x f8c34f4b8d62afad3f63cf3d9617d73735bef8c1
>
> of course to know that you need the previous commit (f8c34f4b8d62afad3f63cf3d9617d73735bef8c1^)
> you most likely would try without the previous first, notice conflicts
> then look at why are there conflicts and then either pick more commits
> or resolve the conflicts by hand
>
> [...]

Thank you Michael, that was helpful.

Mats



More information about the ffmpeg-devel mailing list