Jeff King <peff@xxxxxxxx> writes: > No. git apply is intentionally much more strict about applying under the > assumption that it is better to force a conflict than to silently apply > something that has a reasonable chance of being completely wrong. > > And usually it is not a big deal because falling back to the 3-way merge > is a much nicer way of handling any conflicts _anyway_ (I find .rej > files so much more useless than conflict markers, personally). > > In this case I was able to: > > 1. git am /the/patch > 2. patch -p1 <.git/rebase-apply/patch > 3. manually inspect the results for sanity, and fix up the cache.h > bit that failed totally > 4. git add -u && git add notes.[ch] > 5. git am --resolved I usually skip 2-4 and edit .git/rebase-apply/patch in place instead, and run "git am" instead of step 5. Why was the patch, that was based on something that is clearly different from what other people work on, sent to the list in the first place? IOW, what good does it do to show your patch if other people (plural) need to spend a lot of time and head-scratching? -- 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
