Hi Torsten, On Wed, Feb 12, 2025 at 07:12:36AM +0100, Torsten Bögershausen wrote: > > - Set up a clean filter which enforces CRLF (yes, for this specific use > > case I want CRLF even on linux) > > In general, clean filters do their work when 'git add' or 'git commit file' > is run. Yes. This is done in the renormalise-helper shell script, which I included into my description below: > > $ cat renormalization-helper > > #! /bin/sh -e > > git add --renormalize . > > git diff --quiet --cached || \ > > git commit --amend --no-edit > Does the filter do the CRLF conversion ? As I wrote above: yes, the clean filter enforces CRLF > Or is it done in .gitattributes ? No. .gitattributes states that git should not modify the file since I have set it -text, as I wrote: > > */P -text filter=etsfile > > - Run the renormalization for the linear history: > > > > $ git --attr-source=$(git rev-parse HEAD) \ > > rebase --root -X renormalize \ > > -x $(dirname $0)/renormalize-helper > > That will change the index, the repo, but not the working tree on disk, > right ? "git reset --hard" or even "rm -rf P-0113; git checkout P-0113", also do not bring the CRLF into the file, see below. > > So at this point, I'd expect the falie to have CRLF line endings. But it > > doesn't, so I do: > > > > $ rm -rf P-0113 > > git checkout --attr-source=$(git rev-parse HEAD) P-0113 > > > > Still no CRLF, so I look at what is stored by git: > > > > $ git --attr-source=$(git rev-parse HEAD) show 873a9b:P-0113/P |less -U > > > > Again, no CRLF. > > Just to make sure: > You want to see the CRLF in the files on disk ? In the first place I want to see them in the repo. And a fresh checkout should bring them into the files on disk, since -text is in effect. > Do you have a valid .gitattributes file on disk now ? git recognizes my setting -text and filter=etsfile, as I wrote: > > $ git --attr-source=$(git rev-parse HEAD) check-attr -a P-0113/P > > P-0113/P: text: unset > > P-0113/P: filter: etsfile > If yes, what does 'git ls-files --eol P-0113' say ? As I wrote above: > > $ git ls-files --eol P-0113/P > > i/lf w/ attr/-text P-0113/P > What does 'git status' say ? Nothing, since git add --renormalize . && git commit --amend --no-edit have been done by the helper script on every commit of the history > > So I check all revisions in the history. Resut: no revision has CRLF. > > So the renormalization process does not work for me at all. > > In general, renormalization is about the content inside the repo. > If a filter is applied, or .gitattributes are changed, the files > on disk are not updated automatically. This is why I checkd the contents which are stored in the repo: > > $ git --attr-source=$(git rev-parse HEAD) show 873a9b:P-0113/P |less -U > 'mv -f P-0113 /tmp && git checkout P-0113' may be needed. Well, I did this instead: > > $ rm -rf P-0113 > > git checkout --attr-source=$(git rev-parse HEAD) P-0113 > Yes. The best thing to do (tm) would be to create a dummy repo, > do all all the operations from scratch and post the stuff here. > In other words, write a shell script that creates an empty repo, > fills it with content, and does all the operations. > That would enable people to reproduce it and look what is going on. > Hope that make sense. Well, if I _knew_ what triggers the problem, I could create such a script. As long as I can not figure what triggers the problem, I have to dig into internals of this old repo with long-running history. -- Josef Wolf jw@xxxxxxxxxxxxx
