On 11.09.24 21:47, Marton Balint wrote:
The order of the patches is wrong. Every point in a series must be
compilable, and a patch in a series must only depend on earlier patches
in the series.
So as a first patch you should add codec ID and codec desc, then you can
add MXF demuxer support, then the parser and the decoder. And when
adding the parser/decoder, also make the needed changes in the Makefile,
not just as a separate patch.
You're right! I already recognized this defect yesterday when I saw the
patchwork results. :(
I'm really unhappy about all this troubles related to git jugging and
commit history modification.
On one hand I understand the demand for better reviewable small chunks
of code -- and really appreciate all enormous valuable feedback here on
the list! --, but I also see the inevitable drawbacks of this kind of
workflow.
I'm rather sure, that nobody had recognized, that beside tiny fixes and
rearrangements of this last patch set one file simple got lost.
I therefore personally prefer to use git version control not so much as
a utility to create fancy code rearrangements and cosmetic cleanup, but
as tool to control immutable history and traceable actual code changes,
which it was made for.
In case of horrible sloppy developers like me, this may even uncover and
blame questionable professional qualities by just unforgiving document
all this frequently corrected typos and ugly glitches. But at the end
it's still a rather useful instrument to correct and overcome exactly
this kind of flaws.
I'm therefor unsure, if I'll really follow your advice and waste even
more time on this error-prone code juggling game or just squash all the
changes again to a reliable working bundle satisfying the final
dependencies?
These more structured little code components, which will always compile
if applied one after the other, may indeed look useful and seducing, but
they would have to work even if applied in reverse order if they really
represent individual pickable entities.
Well -- I'll see what I can do to make everybody happy...
Martin
_______________________________________________
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".
