From: Omar Polo <op@omarpolo.com>
Subject: Re: histedit folding "delete, re-add" is broken
To: Stefan Sperling <stsp@stsp.name>
Cc: Christian Weisgerber <naddy@mips.inka.de>, gameoftrees@openbsd.org
Date: Thu, 09 Mar 2023 16:55:18 +0100

On 2023/03/08 16:35:14 +0100, Stefan Sperling <stsp@stsp.name> wrote:
> > This is a delete (local change) vs. add (incoming change) on a file, and
> > hence a tree conflict (per classification the SVN project has been using).
> > 
> > This appears as a tree conflict during histedit fold because fold is
> > implemented by merging (cherrypicking) multiple commits into the work 
> > tree in sequence, with the changes from commit N appearing as local
> > modifications when commit N+1 gets merged. In 'got status' terms we see
> > local state 'D alpha', and the change being merged is 'A alpha'.
> > 
> > I agree we should tweak our merge logic to "restore" the added incoming
> > file even if that file has been locally deleted. There are two similar
> > cases to consider.
> > 
> > One case is where alpha was renamed, rather than deleted:
> > 
> >   git mv alpha alpha2
> >   git commit
> >   echo "unrelated content for unrelated file alpha" > alpha
> >   git add alpha
> > 
> > And this case which is covered by your test:
> > 
> >   git rm alpha
> >   git commit
> >   echo "restore alpha, perhaps with tweaks" > alpha
> >   git add alpha
> > 
> > In either case a deletion event for file alpha will appear while merging
> > the changes in sequence, followed by an addition event. In both cases the
> > desired merge result would likely be to re-add file alpha with its new
> > content. I don't see an obvious alternative way of resolving these cases.
> > So your proposal makes sense to me.
> 
> Here is a fix for this. ok?

ok op