Hi On Sat, Mar 29, 2025 at 01:45:38AM +0000, softworkz . wrote: > > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > Michael Niedermayer > > Sent: Samstag, 29. März 2025 02:17 > > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: Proof of Concept: enable > > out-of-tree filters > > > > 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 > > Hi Michael, > > I suppose you haven't looked at the video. What it is showing are conflicts > in exactly all of those files where you think it would be easy going for Git, > but unfortunately that's not the case. Even a simple one-line addition can > create large conflicting blocks (many lines). This is what I'm talking about > and I've created that video because it's not what you would expect to happen, > but it happens all the time and it's often a much bigger annoyance than API > adaptions. > > It's not quite clear why it happens, maybe it has something to do with how > Git identifies the context areas of changes. I'm wondering whether it could > handle it better if there were one or two blank lines in-between..?
can you show an example with command line git ? like a simple sequence of commands that result in problems, that i can replicate to look at what happens exactly git merge is widely used in project MUCH bigger than our codebase thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell
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".
