Re: renormalize histroy with smudge/clean-filter, again

From: Josef Wolf <jw@raven.inka.de>
Date: Feb 12, 2025, 08:18 UTC
Message-ID: <20250212081842.GR30202@raven.inka.de>
In-Reply-To: <20250212061236.GA990@tb-raspi4>

Hi Torsten,

On Wed, Feb 12, 2025 at 07:12:36AM +0100, Torsten Bögershausen wrote:

Show 5 quoted lines

> > - 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:

Show 5 quoted lines

> >     $ 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

Show 8 quoted lines

> > - 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.

Show 14 quoted lines

> > 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

Show 6 quoted lines

> > 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

Show 6 quoted lines

> 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@raven.inka.de