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).
The difference here seems to be that you actively modify tests/ref/fate/sub-scc, which causes git to consider the file as needing to be restored when you run git reset.
When fate updates from one version to another, the files won't be locally modified, i.e. git's stat cache or similar has this file flagged as "not dirty".
So I suggest you retry your procedure by not manually modifying the file, but just letting git handle it, simulating exactly what happens on fate instances when updating from one version to another.
I.e., first check out 7bf1b9b3576~, nuke the file and check it out again, make sure that it contains CRLF. Then check out current master, which lacks attributes, but the local file in your workdir still contains CRLF. Then do any series of "git reset --hard", with/without "-c core.autocrlf", to commits on your experimental branch, and it won't change the line endings of the ref file, unless there actually are content changes to that particular file, between the git commits that you do check out.
// 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".
