Re: renormalize histroy with smudge/clean-filter

From: Elijah Newren <newren@gmail.com>
Date: Feb 6, 2025, 08:07 UTC
Message-ID: <CABPp-BFZ3oyKiryKMPph+nfokC=sFa7wn1wdas863273bzy7pA@mail.gmail.com>
In-Reply-To: <Z6QCX1QZxxwC7RVQ@tapette.crustytoothpaste.net>

On Wed, Feb 5, 2025 at 4:29 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 19 quoted lines

>
> On 2025-02-05 at 23:59:31, Josef Wolf wrote:
> > > > BTW: It does not make any difference whether I add "-c merge.renormalze=true"
> > >
> > > That option also does not exist.
> >
> > Well, this is described in git(1) manpage:
> >
> >    [ ... ]
> >    SYNOPSIS
> >        git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
> >    [ ... ]                                            ^^^^^^^^^^^^^^^^^^^
> >
>
> The -c option does exist, and apparently the merge.renormalize option
> does as well, so I apologize.  It looks like it's only used in
> merge-recursive and not merge-ort.c, so I'm not sure if it's still
> effective.  Elijah would know for certain, since he's the author of
> merge-ort as well.

init_*merge_options() are defined in merge-recursive.c, and these call merge_recursive_config() which is also in merge-recursive.c, but the parsed options are shared between the two backends; you'll note that merge-ort.h includes merge-recursive.h to get all these. And merge-ort does have the necessary code to use and understand the merge.renormalize option. (Of course, the fact that renormalization *requires* an index made it a bit nasty, because merge-ort was written to avoid the index as a data structure, so I had to do some ugly shenanigans in order to support that option -- https://lore.kernel.org/git/CABPp-BE1TvFJ1eOa8Ci5JTMET+dzZh3m3NxppqqWPyEp1UeAVg@mail.gmail.com/. But that's beside the point here.)