Re: renormalize histroy with smudge/clean-filter

From: Elijah Newren <newren@gmail.com>
Date: Feb 8, 2025, 00:23 UTC
Message-ID: <CABPp-BFGUa_DRBe1WLVfCOKh53+F15KxW_c_OZAMwZCxuAQCiw@mail.gmail.com>
In-Reply-To: <20250207203248.GG30202@raven.inka.de>

On Fri, Feb 7, 2025 at 12:34 PM Josef Wolf <jw@raven.inka.de> wrote:

Show 10 quoted lines

>
> On Fri, Feb 07, 2025 at 06:01:43AM -0800, Elijah Newren wrote:
> > On Fri, Feb 7, 2025 at 3:13 AM Chris Torek <chris.torek@gmail.com> wrote:
>
> > renormalizing
> > all files proactively in the merge machinery whenever a merge or
> > cherry-pick is done would be orders of magnitude slower for any
> > decently sized repository; it's simply out of the question.
>
> Sounds like trade of time against correctness?

I may have misunderstood what folks were saying in my reading & skimming of this thread. I thought some folks were suggesting

   git rebase --root -X renormalize

as a way to renormalize the history, assuming you have linear history. I was arguing against that; it's not going to work and isn't meant to[1]. I also see I didn't look closely enough at Phillip's suggestion, which was:

   git rebase --root -x 'git add --renormalize . && { git diff --quiet
--cached || git commit --amend --no-edit; }'

which will work if you do a lot of manual work to resolve line ending difference conflicts. Since the git add at each step will modify the files on which the next commit is based, that causes the application of the subsequent commit to conflict, and you probably will have difficulty seeing those conflicts since they tend to just be line ending differences. But, mixing that with Brian's suggestion, you get:

  git rebase --root -X renormalize -x 'git add --renormalize . && {
git diff --quiet --cached || git commit --amend --no-edit; }'

which should probably work if you have a linear history (though I've never tried it myself; I've never actually used the renormalization stuff beyond making sure that merge-ort matched merge-recursive). The `git add --renormalize .` does the work of changing files, and the `-X renormalize` to git allows it to handle merging subsequent commits with the munged line ending differences as it does its work.

Were you trying one of these three?  Or something else?

Elijah

[1] The renormalize option to the merge machinery ensures that new blobs produced by the merge have normalized content, and avoid conflicts when the only differences between files are normalization ones. This option does not ensure that new trees only reference new content nor that they only reference normalized content; _any_ pre-existing blobs in the repository are fair game for new trees to reference. As per the manual: "renormalize...This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge..." So, the existing behavior of the renormalize option to rebase/cherry-pick/merge is correct. It may not be what you want, but I don't think cherry-picking/rebasing/merging with the renormalize option is the right tool for this job.