Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx> writes: > I think this is where our two thinking paths diverge. You are > suggesting I edit and fix the patch. Yes, occasionally I do > that, if it is a trivial context change. But hand editing a > patch is not for Joe Average, and gets very complicated in all > but the trivial cases. In your patch, you do not special case and refrain from giving the location of the patchfile when there is only one patch in the input, so the above does not matter anyway. The patch does two unrelated things: reveal the location of the actual patchfile that failed to apply which was so far kept sekrit, and tell the user what to do with it. Because a user who _wants to_ use a patch, once she knows where it is, would know her favorite way of working with it (be it by editing it and reapplying, running "git apply" with --reject or reduced context lines, or running "patch"), an advice on _what_ to do is of secondary importance between the two. Perhaps we can postpone the discussion on that and first update the code to tell _where_ the patch is to the user? That would be an improvement from the current codebase no matter what your faviourite workflow is. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html