Paul Gortmaker <paul.gortma...@windriver.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html