On Fri, Feb 07, 2025 at 04:23:45PM -0800, Elijah Newren wrote:
> I may have misunderstood what folks were saying in my reading &
> skimming of this thread. I thought some folks were suggesting
>
> git rebase --root -X renormalize
>
> as a way to renormalize the history, assuming you have linear history.
Yes. And this did not work.
Then there was Brian's suggenstion, so I tried:
git rebase --root -x 'git add --renormalize . && git commit --amend --no-edit'
which won't work because not every commit touches a filtered file, so I also
tried:
git rebase --root -x 'git add --renormalize . && git status --quiet -uno | git commit --amend --no-edit'
which also did not work. Looks like git-status always exits with success. Why?
> I was arguing against that; it's not going to work and isn't meant
> to[1]. 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, and you probably will have
> difficulty seeing those conflicts since they tend to just be line
> ending differences.
This did not work also: generated LOTS of conflicts.
Oh, have I mentioned that I am not only about line endings? Yes, I mentioned
it in the very first mail. In addition to line endings, I am also about XML
files from a proprietary application which reorders the XML-elements into a
random order every time it ist run. So the clean-filter needs to sort the
XML elements into some "canonical" order.
> 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; }'
Yes, this finally works, IF
git add --renormalize . && git commit --amend --no-edit
is run before starting the rebase process.
BTW: why won't
git rebase --root -X renormalize \
-x 'git add --renormalize .' \
-x 'git diff --quiet --cached || git commit --amend --no-edit'
work?
> Were you trying one of these three? Or something else?
Yes. And even more...
Oh, the application I am talking about also tracks changes in those XML files
in corresponding hash files. I added those hash files into .gitignore and
re-create them in the smudge-filter. This works fine so far, but it also
generates lots of conflicts during renormalization. So I created a helper for
the -x parameter of the renormalize-process to also remove those hash files:
#! /bin/sh -e
find gt8/ETS/Projekte/* -maxdepth 1 \
-name "[BDGIUP].ets5hash" -o \
-name "P-*.ets5hash" \
-print0 \
| xargs -r0 git status --short -uno \
| sed -n "s/^...\(.*\.ets5hash\)$/\1/p" \
| xargs -r git rm -f git --attr-source=$(git rev-parse HEAD) diff --quiet --cached || \
git --attr-source=$(git rev-parse HEAD) commit --amend --no-edit
git --attr-source=$(git rev-parse HEAD) add --renormalize .
git --attr-source=$(git rev-parse HEAD) diff --quiet --cached || \
git --attr-source=$(git rev-parse HEAD) commit --amend --no-edit
But no matter how I construt this, the renormalize keeps conflicting on these
files. Whehn I do
git rm -f gt8/ETS/Projekte/XXX/U.ets5hash
git --attr-source=$(git rev-parse HEAD) commit --amend --no-edit
git rebase --continue
manually, it works fine. Why won't the git-rm work when called from git-rebase directly?
> [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. At least when --renormalize
is in effect. Using smudged content for diff/merge operations is a sure recipe
for failure.
> 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
--
Josef Wolf
jw@xxxxxxxxxxxxx
