Re: renormalize histroy with smudge/clean-filter

From: Elijah Newren <newren@gmail.com>
Date: Feb 8, 2025, 21:56 UTC
Message-ID: <CABPp-BGQ0pc=AZ0fdXcqDbhMLbm2xBvi71g0mXAVDagz19NkEg@mail.gmail.com>
In-Reply-To: <20250208205709.GH30202@raven.inka.de>

On Sat, Feb 8, 2025 at 12:58 PM Josef Wolf <jw@raven.inka.de> wrote:

>
> On Fri, Feb 07, 2025 at 04:23:45PM -0800, Elijah Newren wrote:

[...]

Show 12 quoted lines

> > [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.
>
> OK.
>
> But then, non-normalized content should go through the clean-filter before it
> is handed over to diff/merge when filtering is active.

Not quite; if the diff/merge doesn't need to look at the content of the file to resolve the merge (i.e. the merge can simply use the file's already known hash as the resolution), then, since that content isn't read it shouldn't go through any filters.

Whenever you merge two trees, only the files modified on both sides need to be inspected; the rest can be resolved without looking at their content.

Show 14 quoted lines

> > 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.
>
> A virtual check-out and check-in should result in smudge+clean. Running this
> on smudged content results in smudge+smudge+clean. Which by definition is
> equivalent to a simple clean. No conflicts shoud happen, then.
>
> So the _description_ looks correct. But where do the conflicts coming from?
>
> > It may not be what you want
>
> I don't see how the description matches actual behaviour

The description says "This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge..."

So, when a file needs a three-way merge to be resolved, then the virtual check-out and check-in is done. When no three-way merge is needed for a file, no virtual check-out and check-in is done.

Perhaps the documentation would be clearer if it read:

           renormalize
               This runs a virtual check-out and check-in of all three stages
               of any file which needs a three-way merge.