On Fri, Feb 7, 2025 at 12:34 PM Josef Wolf <jw@xxxxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxx> 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.
