Thanks for all the insights and explanations! I have to admit that I have a hard time to understand why the merges (and even conflicts) happen. I have a totally linear history here. Thus, I'd expect the rebase to do something like (in pseudo-code) foreach $commit original-branch-commits git cherry-pick $commit So I tried this and I see that cherry-pick seems to ignore the clear-filter setting and commits the smudge'd version? My expectation would have been that every operation would run the clear filter before storing it in the repo. Why is not everything going into the repo cleared? On Thu, Feb 06, 2025 at 12:07:00AM -0800, Elijah Newren wrote: > On Wed, Feb 5, 2025 at 4:29 PM brian m. carlson > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > 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@xxxxxxxxxxxxxx/. > But that's beside the point here.) > > -- Josef Wolf jw@xxxxxxxxxxxxx