On Fri, Jun 17, 2022 at 11:48:31AM +0200, Omar Polo wrote:
> Stefan Sperling <stsp@stsp.name> wrote:
> > On Thu, Jun 16, 2022 at 12:35:31AM +0200, Omar Polo wrote:
> > apply_patch() seems to treat the occurrence of a merge conflict as a
> > fatal error. Why?
> 
> in fact, i don't want to treat them as fatal error.  The idea was to use
> GOT_ERR_PATCH_CONFLICT to signal the caller (got_patch) that a conflict
> was found, but not to stop the patch operation.  (like what happens for
> a failed patch, so that in the end 'got patch' exits with non-zero)
> 
> I lost a change in got_patch when putting the diff into shape, thanks
> for spotting this!

You could instead pass overlapcnt back to the caller.

> it's nice thought how the output of 'got diff' is so easy to parse
> already, was it written with a 'got patch' in mind? :)

Yes, the idea was the make it possible to find related objects in
the repository when reading the diff. And even just for human
cosumption this is already an advantage because you can back-date
your work tree such that the patch will apply cleanly, and then
merge in newer changes with got update, or even the commit changes
found in the patch to a branch and cherrypick them elsewhere.
What you are doing here with 'got patch' automates this.