Re: renormalize histroy with smudge/clean-filter

[Elijah Newren <newren@gmail.com>]

On Fri, Feb 7, 2025 at 3:13 AM Chris Torek <chris.torek@gmail.com> wrote:
>
> > and (in the case of cherry-pick) there is not even any way to
> > renormalize before picking.
>
> That's mostly correct. The problem here is that while `git merge`
> (both recursive and the new ort) has a renormalize option
> internally, it's not exposed to cherry-pick.

Perhaps not as a config option, but it can be selected via -Xrenormalize .

However, whether it is exposed or used doesn't matter.
Renormalization in the merge machinery (this is the same for both the
recursive and ort backends) is something passed to xdiff[1], for doing
3-way content merges of individual files. If a
merge/rebase/cherry-pick/revert doesn't need to do a 3-way content
merge for some file, then no normalization will be done for it.  This
could happen, for example, if one side of history being merged
modified a file and the other side of history being merged didn't
touch that file.  And as a special case, that includes when one side
of history adds the file and the other side of history doesn't have
the file.

In particular, for the cherry-picks or rebasing that Josef is doing
going back to the root of history, that is simply doing merges against
a side of history that hasn't modified any of his files, so there
isn't going to be any automatic renormalization.

The rest of what you write about optimizations is spot on, though.
This isn't a bug in cherry-pick (or merge or rebase); 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.  I think
Phillip's suggestion elsewhere in this thread (git rebase --root -x
'git add --renormalize . && { git diff --quiet --cached || git commit
--amend --no-edit; }') would be what Josef needs to run, ASSUMING the
history Josef is operating on is linear.

Hope that helps,
Elijah

[1] Okay, technically renormalization is also used to turn
modify/delete conflicts into simple deletes, when the only
modification was a normalization of the file contents.  I don't think
that's relevant to Josef's case, though, so I elided it in the
explanation.