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 <barsn...@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@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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
