Hi On Fri, Mar 28, 2025 at 10:23:50PM +0000, softworkz . wrote: [...] > > > > The advantage of "git merge" wether by hand or by a automated tool > > is that its not limited to what it can do. Its much more powerfull > > Git merge only works when there's a common baseline and the only difference > is the filter commit on top that you want to merge. It cannot be used when > there are different baselines, e.g. the filter is on top of a the latest > master branch and you want to merge it into an older (release) branch, as > that would add all the differences, not just the filter. > What you can do is cherry-picking the commit which adds the filter, but the > bigger the differences of the baseline, the bigger the problems when > cherry-picking. > > > > and the changes outside adding the filter itself are very basic. > > Conflicts are something that we can workaround in many ways if they > > become a problem > > The changes are basic in fact, but the trouble it is causing each time is > beyond basic. > > To give you an idea of what I'm talking about I've recorded a short > screencast to illustrate what I mean: > > https://gist.github.com/softworkz/750da15adb259fa13c6b32277647d54e
Conflicts can only occur in areas belonging to more than one module
ATM, when adding a filter thats allfilters.c, Makefile, doc/filters.text and
configure
(and very similar files for other things than filters)
As nicolas suggested, if each filter is in its own directory no conflict
is possible.
configure just needs to include the Makefile, doc/*.texi, allwhatever.c
from each of these directories
About merges and revission differences.
A filter for ffmpeg 2.0 will possibly not work with 1.0 (in the currect
designs of using the internal API/ABI)
So if you have a filter based on 1.0, one on 1.0.3 and one on 1.0.8
and you merge these with the ffmpeg release 1.0.12
you get exactly the right thing full automatically
You can cherry pick too and the effect is about the same but if filters
share a common component merging will likely be less conflicting
What iam suggesting, i guess is,
* allow new modules to live in seperate directories
(even without any external modules this gives us fewer conflicts)
* maintain a simple list of such externally maintained modules on
ffmpeg.org (users need a place to find these modules, especially
in a world where mallicious code is becoming more widespread)
* really the user can use git merge directly but we could give him
a tool that gives a clearer success/fail and leaves no failed merges
secret-plan: every halloween we release ffmpeg-monster that merges EVERY
actively maintained module which dosnt conflict. (this would also
encourage module maintainers, to maintain their code)
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
