On Sat, Mar 12, 2022 at 02:32:18PM +0100, Omar Polo wrote:
> 
> While this is perfectly fine for patch(1), i'd like (if possible) for
> got to not do this.  One important advantage got patch has over patch(1)
> is that we _know_ which files are part of the repository and which
> don't.  We don't have to guess.  Or at least, I'd like if we can manage
> not to resort to guesses and heuristics :)

This is not a valid assumption in all cases, unfortunately, at least
if by 'files' you actually mean 'file paths'.

The patch could have been created against a subdir of the source tree
(in a work tree obtained by 'got checkout -p', or with /usr/bin/diff -u)
and may lack leading path components that exist in the repository.

For added files, any existing parent directories of the added path
could provide guidance.
But consider patches which only add new files in new directories which
do not even exist in the root of the work tree. In this case, there is
no way of knowing how file paths correspond to paths which already exist.
You don't know what the actual parent path of the relative paths was when
the patch was created.

One thing you can rely on are object IDs printed by 'got diff' if they
are available. This might be of good help in some cases.
E.g. you could check whether deleting a file actually deletes a versioned
file which corresponds to the blob ID given in the patch; else you may want
to avoid deleting the file, perhaps as an optional safety check which the
user is allowed to override. This would be an "edit vs. delete" conflict
in SVN, which may be upgraded to "edit vs. rename" during conflict resolution,
and then automatically resolved by applying the edit at the post-rename
location. (Got might eventually get a similar conflict resolution system;
'svn patch' does not support conflicts yet, and I don't remember what
it does in the "edit vs delete" case, maybe it creates a reject file;
'svn update' and 'svn merge' would definitely flag it as a conflict).

> It's not perfect yet, in particular this means that at the moment `got
> patch' fails on partial checkouts (i.e. `got co -p') and diff for
> relative paths (the one you generate with cvs in a subdirectory for
> instance), but I think we can fix these issues in a different way.

To some degree you will have to rely on the ability of people to obtain
a good work tree for applying a patch. The sanity checks you will need
to perform on a per-path basis anyway should suffice to catch mistakes
where the work tree is incompatible somehow.