NotADirectoryError in Trash.backupFile when resolving "deleted by both" merge conflict

[f5inet]

Description

When resolving a merge conflict where a file has been deleted in both the local and upstream branches, selecting "Accept both changes" (or confirming the deletion) causes GitFourchette to crash with a NotADirectoryError. The error occurs while trying to back up the file to the trash.

Steps to Reproduce

1. Have a repository with a merge conflict where the same file is deleted in both branches (e.g., git merge upstream/main).
2. In GitFourchette, open the merge conflict resolution view.
3. Select the conflicting file (which is marked as deleted in both sides).
4. Choose to accept both changes (or confirm the deletion).
5. GitFourchette throws the error and fails to complete the merge.

Expected Behavior

The merge should complete successfully, marking the file as deleted, without any error.

Actual Behavior

GitFourchette shows an error dialog:

Operation failed: Accept/reject incoming changes.

NotADirectoryError: [Errno 20] No es un directorio: '/var/home/f5inet/Proyectos/Historic340/.opencode/agents/accessibility-specialist.md'

Full Traceback

Traceback (most recent call last):
repotask.py:1142, in _getNextToken
token = next(flow)
indextasks.py:346, in flow
Trash.instance().backupFile(repo.workdir, path)

trash.py:91, in backupFile
^^^^^^^^^^^^^^^^^^^^
if self.maxFileSize != 0 and os.lstat(fullPath).st_size > self.maxFileSize:
~~~~~~~~^^^^^^^^^^
NotADirectoryError: [Errno 20] No es un directorio: '/var/home/f5inet/Proyectos/Historic340/.opencode/agents/accessibility-specialist.md'

System Information

• GitFourchette version: 1.8.0, Flatpak
• Operating System: Linux Bazzite 44 - nVidia Edition
• Git version: 2.54.0
• Python version: 3.14.5

Workaround

Resolve the conflict via the command line:

git rm --cached .opencode/agents/accessibility-specialist.md   # or for multiple files

after that, continue in gitfourchette GUI.

Possible Fix (Source Code Analysis)

The error occurs in trash.py:91 inside backupFile:

if self.maxFileSize != 0 and os.lstat(fullPath).st_size > self.maxFileSize:

The issue is that fullPath points to a file, but the code attempts to use os.lstat() on it as if it were a directory. This happens because backupFile is being called with a file path, but the function likely expects a directory.

[jorio]

Thanks for the report! I'm working on a fix for the next version.

Re: your analysis - os.lstat does accept paths to files, but it can raise NotADirectoryError if any non-final part of the path isn't a directory. In your scenario, I believe .opencode/agents used to be a directory and became a file, so calling lstat on .opencode/agents/....md fails.