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. > > git rebase --root -x 'git add --renormalize . && git commit --amend --no-edit' > > Unfortunately, this runs the command on every commit and gives a warning when > a cmmit don't touch a filtered file: > > $ git rebase --root -x 'git add --renormalize . && git commit --amend --no-edit' > [ ... ] > No changes > You asked to amend the most recent commit, but doing so would make > it empty. You can repeat your command with --allow-empty, or you can > remove the commit entirely with "git reset HEAD^". Yeah, that's a problem with a rebase in general here. You could try `git rebase --root -X renormalize` here, which will use the `renormalize` option, but you may run into the same problem. I _think_ with the default merge strategy in rebase that it will keep the empty commits, so your linear parts of history won't be changed, although you'll probably drop the merge commits (and any conflict resolutions) unless you use `--rebase-merges`. If this is a small project, that may not be a problem, but I would recommend `git filter-repo` here if that's an option because it will preserve your history in a nicer way. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
