Re: What's the recommendation for forgetting all rerere's records?

There was enough going on with that prior email that I gave it another look and found some errors.

This section should have read:

    $ echo 'bad merge' >file
    $ git add file

    $ EDITOR=: git rebase --continue
    Recorded resolution for 'file'.
    [detached HEAD 5e3c431] local
     1 file changed, 1 insertion(+), 1 deletion(-)
    Successfully rebased and updated refs/heads/feature.

    $ git reset --hard @{1}
    HEAD is now at b4d7aeb local

    $ git rebase main
    Auto-merging file
    CONFLICT (content): Merge conflict in file
    error: could not apply b4d7aeb... local
    hint: Resolve all conflicts manually, mark them as resolved with
    hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
    hint: You can instead skip this commit: run "git rebase --skip".
    hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
    Resolved 'file' using previous resolution.
    Could not apply b4d7aeb... local

    $ git checkout --merge .
    Recreated 1 merge conflict

    $ git rerere forget .
    error: no remembered resolution for 'file'

I've driven myself a little nuts trying to reproduce it this morning, but in doing so I've come to an important discovery: this bug presents if `core.autocrlf=true` but does *not* present if `core.autocrlf=input`.

For completeness and future reference, the following script reproduces the issue on Windows:

    git init
    echo aaa >file
    git add file
    git commit -ambase
    git branch feature
    echo bbb >file
    git commit -amremote
    git switch feature
    echo ccc >file
    git commit -amlocal
    git config rerere.enabled true
    git config core.autocrlf true     # <--

    # setup complete; let's rebase!
    git rebase main
    echo 'bad merge' >file
    git add file
    EDITOR=: git rebase --continue

    # uh oh; that was a bad resolution; let's try again
    git reset --hard @{1}
    git rebase main
    git checkout --merge .
    git rerere forget .               # fails
    echo 'good merge' >file
    git add file
    EDITOR=: git rebase --continue

At the end of this script, the 'bad merge' is still the recorded resolution and no rerere record exists for the 'good merge'.

Just in case there's another piece of config somehow relevant, here's a dump of the system that reproduced this:

    $ git config --list --show-scope | sort
    global	user.email=[clip]
    global	user.name=[clip]
    local	core.autocrlf=true
    local	core.bare=false
    local	core.filemode=false
    local	core.ignorecase=true
    local	core.logallrefupdates=true
    local	core.repositoryformatversion=0
    local	core.symlinks=false
    local	rerere.enabled=true
    system	core.autocrlf=input
    system	core.fscache=true
    system	core.fsmonitor=true
    system	core.symlinks=false
    system	credential.helper=manager
    system	credential.https://dev.azure.com.usehttppath=true
    system	diff.astextplain.textconv=astextplain
    system	filter.lfs.clean=git-lfs clean -- %f
    system	filter.lfs.process=git-lfs filter-process
    system	filter.lfs.required=true
    system	filter.lfs.smudge=git-lfs smudge -- %f
    system	http.sslbackend=schannel
    system	http.sslcainfo=C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt
    system	init.defaultbranch=main
    system	pull.rebase=true

    $ git --version
    git version 2.43.0.windows.1

It's worth noting at this point that while I believe I reproduced on macOS last week, that doesn't jive with the available evidence (and I can't reproduce it on macOS this morning, though I suspect that has more to do with native use of LF over CRLF than anything else).

-- Sean Allred