Hi

On Sat, Mar 29, 2025 at 01:45:38AM +0000, softworkz . wrote:
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@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