On Wed, Jul 27, 2022 at 09:37:11AM +0200, Omar Polo wrote:
> this allows to apply a patch at a specified commit; it's useful for e.g.
> when trying to apply an old CVS-generated diff that may not apply
> cleanly (or at all.)
> 
> my initial version would only use -c to supplement missing information,
> a second revision (the one below) instead always use the -c provided
> commit, overwriting the existing metadata in the diff eventually.
> 
> (the rationale for this is that we may want to apply a diff generated
> from another repository where the commit/blob ids are different.  pretty
> narrow use-case, but if one specifies -c i think we should respect it.)

Yes, -c should always be respected if specified.

> ok?

Yes, I have just some documentation nits:

> @@ -1401,6 +1401,16 @@ The options for
>  .Cm got patch
>  are as follows:
>  .Bl -tag -width Ds
> +.It Fl c Ar commit
> +Use files in the specified

s/files in/files found in/ ?

> +.Ar commit
> +to find a merge-base, overriding the meta-data in

"use files ... to find a merge-base" could be more accurately expressed
like this: "use files ... as a merge base for 3-way merges".

Perhaps we should add a hint that this is an optional flag, and that patch
will work well without it? Otherwise people might wonder if it is required
in case the patch does not carry meta-data?

"In case no merge-base is available for a file,
.Cm got patch
will attempt to apply the changes without doing a 3-way merge."

> +.Ar patchfile
> +.Pq if any .
> +This is useful to apply an old patch that wasn't generated by
> +.Cm got diff
> +or
> +.Xr git-diff 1 .

s/an old patch/a patch/ ? I don't see why such a patch would be "old".
There are many ways to produce patches aside from 'got diff' and 'git diff'
and people will keep using them. Consider 'diff -u file.c.orig file.c'.