From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sat, 08 Feb 2025 11:14:57 GMT
Subject: Re: renormalize histroy with smudge/clean-filter
Message-ID: <ba65ce17-8768-4d60-aec6-badd12930b81@gmail.com>
In-Reply-To: <CABPp-BFGUa_DRBe1WLVfCOKh53+F15KxW_c_OZAMwZCxuAQCiw@mail.gmail.com>

Hi Elijah and Josef

On 08/02/2025 00:23, Elijah Newren wrote:
> On Fri, Feb 7, 2025 at 12:34 PM Josef Wolf <jw@raven.inka.de> wrote:
>> On Fri, Feb 07, 2025 at 06:01:43AM -0800, Elijah Newren wrote:
>>> On Fri, Feb 7, 2025 at 3:13 AM Chris Torek <chris.torek@gmail.com> wrote:
>>
> I also see I didn't look closely enough at Phillip's
> suggestion, which was:
> 
>     git rebase --root -x 'git add --renormalize . && { git diff --quiet
> --cached || git commit --amend --no-edit; }'
> 
> which will work if you do a lot of manual work to resolve line ending
> difference conflicts.  Since the git add at each step will modify the
> files on which the next commit is based, that causes the application
> of the subsequent commit to conflict,

Indeed, I'd missed that (like you I've not actually used any 
smudge/clean filters)

> and you probably will have
> difficulty seeing those conflicts since they tend to just be line
> ending differences.  But, mixing that with Brian's suggestion, you
> get:
> 
>    git rebase --root -X renormalize -x 'git add --renormalize . && {
> git diff --quiet --cached || git commit --amend --no-edit; }'
> 
> which should probably work if you have a linear history

I've tried that out with a small modification in the script below which 
seems to work. The modification is to add "--attr-source=$(git rev-parse 
HEAD)" between "git" and "rebase" so that git always has a 
.gitattributes file to read when rebasing commits that were made before 
that file was added. I wonder if we should add something about 
renormalizing a repository to the FAQ based on your footnote

 > [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.  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.  It may not be what you
 > want, but I don't think cherry-picking/rebasing/merging with the
 > renormalize option is the right tool for this job.
 >

Best Wishes

Phillip

--- >8 ---
#!/bin/sh
set -e
d="$(mktemp -d)"
cd "$d"
git init
echo "The   quick  brown" >file
git add file
git commit -m line-1
echo "fox  jumps    over" >>file
git commit -a -m line-2
echo "the      lazy   dog" >>file
git commit -a -m line-3
echo "file filter=space" >.gitattributes
git config filter.space.clean "sed -e 's/  */ /g'"
git config filter.space.smudge cat
git add .gitattributes
git commit -a -m 'add .gitattributes'
git reset --hard HEAD
git --attr-source=$(git rev-parse HEAD) rebase --root -X renormalize \
     -x 'git add --renormalize . && { git diff --cached --quiet || git 
commit --amend --no-edit; }'
git log -p