[FFmpeg-devel] [FFmpeg-cvslog] lavf/assenc: normalize line endings to \n

Anton Khirnov anton at khirnov.net
Tue Feb 13 11:28:36 EET 2024


Quoting Martin Storsjö (2024-02-12 12:31:29)
> On Mon, 12 Feb 2024, Hendrik Leppkes wrote:
> 
> > On Mon, Feb 12, 2024 at 11:22 AM Martin Storsjö <martin at martin.st> wrote:
> >> >
> >> > diff --git a/.gitattributes b/.gitattributes
> >> > index 5a19b963b6..a900528e47 100644
> >> > --- a/.gitattributes
> >> > +++ b/.gitattributes
> >> > @@ -1,2 +1 @@
> >> > *.pnm -diff -text
> >> > -tests/ref/fate/sub-scc eol=crlf
> >>
> >> This change seems to have had a tricky effect on the
> >> tests/ref/fate/sub-scc file. Previously, when checked out, users got the
> >> file with CRLF newlines. When updating to this git commit, or past it,
> >> that file remains untouched, with CRLF still present, and the
> >> fate-sub-scc test fails. If one does "rm tests/ref/fate/sub-scc; git
> >> checkout tests/ref/fate/sub-scc", then the file does get restored with LR
> >> newlines, and the test passes.
> >>
> >> It's easy to do this change manually in the source checkout of a fate
> >> runner, but I'm not sure how easily we get all fate instances fixed that
> >> way - currently this test is failing in most of them.
> >>
> >
> > Can this be fixed by restoring the .gitattribute entry but with eol=lf?
> > Not sure if Git would reset the file then.
> 
> No, that doesn't seem to make any difference. Not sure if there are any 
> other straightforward/elegant fixes, short of renaming the file, which I 
> guess would require renaming the test itself.

I'm fine with renaming the test, unless anyone has a better fix.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list