On Thu, Jul 14, 2022 at 03:58:57PM +0200, Christian Weisgerber wrote:
> I just ran into another instance where a rebase was interrupted because
> "Files which had incoming changes but could not be found in the
> work tree".  Yes, that file had been deleted.  And the incoming change
> was... to delete it.  Could rebase be smart enough to figure that
> out?

In general: No, not yet.

For Delete vs. Delete there is of course the trivial case where both
sides have deleted the file. Because this case seems so trivial and
common, Got appears to be very stupid when it fails to merge such a change.

But Delete vs. Rename is also a conflict: Should the file disappear or
continue to exist under a new name? (In general, we would need to ask
the user for the answer.)
And without some kind of rename detection the program cannot tell whether
an incoming deletion event represents a "true" deletion or the delete-half
of a rename. So we need to err on the side of caution and somehow alert
the user of a potential problem (and, unfortunately, this alerting is
currently done in a way that will most likely be incomprehensible to
anyone but myself).

I have added a bit of tree conflict handling for specific situations in
merge handlers of lib/worktree.c already. But we are quite restricted in
our possibilities until Got learns to detect renames.

Regardless, it might be possible to improve some behaviour already right
now, but only in very specific cases.
To figure out if improving the current behaviour is possible in the case
you saw, I would need a reproduction script that triggers this exact case.
Without such a script it is difficult to assess what could be done.
Ideally the script would be a regress test so we can keep testing this
behaviour going forward.