[FFmpeg-devel] libav commit f8c34f4b8d62afad3f63cf3d9617d73735bef8c1 (again)
Moritz Barsnick
barsnick at gmx.net
Wed Mar 16 09:59:00 CET 2016
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
More information about the ffmpeg-devel
mailing list