On Fri, Feb 7, 2025 at 2:46 AM Josef Wolf <jw@xxxxxxxxxxxxx> wrote: > I completely fail to understand why git insists to operate on smudged files in > many situations. It doesn't, really, and that's not the basis of the problem with rebase using merge. However: > IIUC, once clean/smudge are installed, all internal operations should be done > on clean files. So why do I need this "git add --renormalize ." at all ... To simplify (perhaps oversimplify, but I'll hope not), you're running afoul of an optimization trick. Git is famously *fast* (as compared to most of the systems that came before or at the same time anyway). In the old days when I used CVS and Subversion and the like, we'd run a commit or update, and then go out for coffee or lunch or whatever, because we knew we were not going to be able to do anything for another ten minutes or perhaps even an hour or more. Then Git came along and we'd run "git checkout" or "git commit" and it would say it was done, often without even a noticeable pause, and we'd wonder if it actually did anything at all. Git gets this speed through a lot of clever tricks, and one of them interacts poorly with clean and smudge filters *if you ever change the filter*. If the filter says constant, the tricks still work -- but what you are doing (in effect anyway) here is to change to a new filter with each commit. Running with an explicit `--renormalize` turns off the efficiency trick. This is documented (indirectly) where > and (in the case of cherry-pick) there is not even any way to > renormalize before picking. That's mostly correct. The problem here is that while `git merge` (both recursive and the new ort) has a renormalize option internally, it's not exposed to cherry-pick. Oddly, checkout obeys it. Perhaps builtin/revert.c should as well? Chris
