On Sun, Mar 13, 2022 at 02:49:00PM +0100, Omar Polo wrote:
> Stefan Sperling <stsp@stsp.name> wrote:
> > > If we strengthen the preconditions so that only unmodified files are
> > > allowed to be changed, than we could run an implicit 'got revert' but
> > > i don't really like the idea.  Producing .rej files (which atm we still
> > > don't do) or conflict markers on failures but still trying to continue
> > > seems the most useful behavior to me, at least by default.
> > 
> > Allowing only M is not a restriction we would want to keep in the
> > long-term. Having files in A and D status should be supported.
> 
> I meant that i'm only allowing M (or m, or A) when need to apply some
> changes to a file.  How could it work for file scheduled for deletion
> (D) ?

Sorry, I misread what you wrote. I read "modified" instead of "unmodified".
Please ignore.

> I thought that if a patch wants to add a file that's already present,
> the user could `rm file' and then apply the diff, turning a conflict
> into an edit.  it's probably too convoluted and the user could just as
> well commit the deletion of the file before applying the diff, and maybe
> do an histedit after.  I've dropped this part.

I would not want to encourage such hacks.
Instead, we may want to allow a file to be added on top of a deleted
path, turning it into modified status. But that can be dealt with later.

> Here's the full sequence of commit with the due corrections :)

Thanks!

Still looking good to me, please go ahead.

One typo in a log message:

>  Simplify some prasing, explain what preconditions `got patch' has and
>  what happens to the work tree when an error occurs.

s/prasing/phrasing/