Re: renormalize histroy with smudge/clean-filter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux