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 <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
[...]
Thank you Michael, that was helpful.
Mats
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
