Re: renormalize histroy with smudge/clean-filter

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

 



On Sat, Feb 8, 2025 at 12:58 PM Josef Wolf <jw@xxxxxxxxxxxxx> wrote:
>
> On Fri, Feb 07, 2025 at 04:23:45PM -0800, Elijah Newren wrote:
[...]
> > [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.

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

?





[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