[FFmpeg-devel] libav commit f8c34f4b8d62afad3f63cf3d9617d73735bef8c1 (again)

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160316/60b9427c/attachment.sig>