Re: renormalize histroy with smudge/clean-filter

From: Elijah Newren <newren@gmail.com>
Date: Feb 7, 2025, 14:01 UTC
Message-ID: <CABPp-BFnx2m75jsa3_kTPet97HY+xwb_6JmPiKM5+OARPy=mGA@mail.gmail.com>
In-Reply-To: <CAPx1GvcyaZqYK+SvgtfsajqtkMty1jOcVAtwfmam-LpOjyd0jw@mail.gmail.com>

On Fri, Feb 7, 2025 at 3:13 AM Chris Torek <chris.torek@gmail.com> wrote:

Show 7 quoted lines

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