Download raw body.
"got patch" format?
On Sat, Mar 19, 2022 at 06:15:23PM +0100, Omar Polo wrote:
> Christian Weisgerber <naddy@mips.inka.de> wrote:
> > I just tried to use "got patch" and promptly failed because I had
> > generated the patch file with "diff -u foo.orig foo", and "got patch"
> > choked because foo.orig didn't exist in the worktree. Is this a bug,
> > work in progress, ...?
>
> patch(1) (and in most cases 'git apply' too) prefer the new path over
> the old path, so in your case both pick up 'foo' as path and it works.
>
> in 'got patch' i tried to handle the rename case too, and in fact at the
> moment it handles "git-style rename diffs" well. This means however
> that both the "old" path and the "new" path must exists in the worktree.
> (see test_patch_rename)
>
> (The only case where 'git diff' produces a diff for a rename that's not
> currently handled by 'got patch' is when a file is renamed without any
> change. in that case the diff has only the header and no hunks in it.)
>
> 'git apply' solves this by requiring some git-specific "annotations" to
> the diff for it to interpret the paths as rename. ("headers" like
> similarity index, rename from/to and the leading "diff --git".) In
> practice thought seems that "diff --git" and paths wit a/ and b/ are
> enough for it to do the rename. I haven't checked the sources and the
> git-apply manpage doesn't mention anything (judging from a quick grep.)
>
> We have multiple way to fix this:
>
> - don't support patches that rename files (can always be achieved by a
> remove folled by the addition of the file like 'got diff' already
> does.)
Given these three options, I would prefer the above, for now.
> - add some heuristics in got_worktree_patch_check_path. We could, for
> instance, ignore the old path and just use the new when the old file
> is nonexistent or unversioned. Diff below is an example of this.
>
> - invent our own annotations? "diff --got" anyone? :D
That would be bad for interop. Everyone else would have to parse our
custom annotation format.
So I think 'got patch' should expect git-compatible annotations,
and only support renames if they are present. We can leave this
for later, it doesn't have to happen right now.
'got diff' might eventually produce git-compatible annotations
instead of full delete + full add.
SVN did this, too. There is 'svn diff --git', and 'svn patch' can
parse Git's annotations. Everyone wins.
"got patch" format?