On Tue, 13 Feb 2024, Ridley Combs wrote:
It looks like checkout has different behavior from reset, and fate uses a
hard reset.
To test, I committed the change adding tests/ref/** -text,
unix2dos'd tests/ref/fate/sub-scc, then ran git -c core.autocrlf=true reset
--quiet --hard; this dos2unix'd the file as expected when run with a working
tree containing the .gitattributes change (but not otherwise).
Git doesn't have any "memory" of the CRLFiness of a file beyond the content
of the file itself (whether in the working tree or in committed blobs). It
just doesn't necessarily replace every file in checkout invocations when
they differ only in line endings. Windows was a mistake.
To rephrase; reset vs checkout doesn't make any difference here.
It seems to simply be the case, that as long as there are no changes to
the file contents themselves between the relevant git commits, and the
file isn't flagged as dirty in the stat cache of the local workdir, git
never revisits the .gitattributes for this particular file.
// 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".
