Han Young <hanyang.tony@xxxxxxxxxxxxx> writes:
> We're using 'git format-patch' and 'git am' workflow to sync changes between two repositories. This works great but I've found an edge case in apply.c
>
> If one commit creates a file whose path has a directory segment ending with space will cause the generated patch unappliable. Here is a script to reproduce the edge case:
>
> mkdir tmp && cd tmp
> git init
> git commit --allow-empty -m empty
> mkdir 'foo '
> touch 'foo /bar'
> git add -A
> git commit -m foo
> git format-patch HEAD~1
> git reset --hard HEAD~1
> git am 0001-foo.patch
That is an interesting corner case. You should make this into a set
of new tests somewhere in t/; I suspect this only will "break" for
creation and deletion but not modification in-place or renaming (and
that should also be in the tests).
But before going into this too deeply.
I have this feeling that we have seen corner cases like this before
and it always turned out that the right solution was to fix the
parser on the "apply" side, not on the generation side. The tools
in the wild _will_ show a patch with a header like:
diff --git a/foo /bar b/foo /bar
new file mode 100644
index 0000000..e25f181
--- /dev/null
+++ b/foo /bar
even after we noticed this problem and started working on a fix, so
making sure future "git apply" can grok such output should be a lot
more fruitful direction to go into, and when it happens, we do not
have to touch the generation side at all. Who knows what external
tools break when we suddenly start quoting a path with a space
anywhere in it, which we never did?
Thanks.
