Re: [PATCH 2/3] Fix the processing of multiple patch files with --check in git-apply.

Robert Fitzsimons <robfitz@273k.net> writes:

Not really controversial anymore, as long as --ignore-applied is used only when appropriate.

Here is another one that the patch seems to regress.

Unfortunately this turns out to be a death sentence to the 'multiple patch touching the same file' patch.

Note that patches from a single 'git-diff-*' run are supposed to be independent, so the second one that copy-edits from frotz to rezrov copies frotz _before_ it is modified and then makes its modification.

On the other hand, we can have one 'git-diff-*' run that modifies frotz in place, and then a separate 'git-diff-*' run that copies frotz to rezrov and then modifies rezrov, and feed the concatenation of the two to git-apply. That would look very similar to a single run that edits frotz and copy-edits rezrov, but the pre-image to create rezrov would use the post-edit image of frotz from the first patch. Without an explicit "here an output from the next git-diff-*' run begins" marker, we cannot tell these two apart.

This means that applying multiple-patches concatenated in a single file does not make much sense. There is no guarantee that we can detect where the first 'git-diff-*' output ends, at which point we need to reset the status of 'frotz' to post-modification image of the first patch. And if we can detect reliably where one 'git-diff-*' output ends and the next one begins, we could just split the input there and run git-apply independently. So my conclusion is to just drop this patch, and instead tell people not to feed overlapping outputs from multiple git-diff-* runs to a single invocation of git-apply.

I personally do not mind considering --ignore-applied independently from the multiple-patch-files changes, though.

------------ echo frotz >frotz git-apply --check <<\EOF