On Tue, Nov 08, 2011 at 12:10:48AM +0200, Ori Avtalion wrote: > I'm trying to get git-apply to apply patches, and let me handle the > conflicts in a way I'm comfortable with -- by staging the "successful" > hunks and leaving conflict markers in the working tree. > > With the available flags, I seem to only be able to have successful > hunks in the index, and rejected ones in patch-like .rej files. > > Is there a way to accomplish this? If not, does anyone think it's a good > idea? No, I don't think there's a way to do it now. I do find the conflict markers the easiest way to mark something up. But most of my "git apply" use is through "git am", which knows the trick of falling back to a 3-way merge (see fall_back_3way in git-am.sh). If it's an actual git diff, the same 3-way trick will yield good results, and it would be nice if it were easier to do that trick without calling "git am". But if it's not a git diff (i.e., missing the original blob information), then you won't be able to do that. In the general case, you can't represent all failed hunks with conflict markers, can you? I'm thinking something where we couldn't find any relevant context. You know the lines from the original patch from the hunk header, so you can drop the failed content from the patch in the right spot. But how do you know how big a conflict marker to make for the "current" side? The same number of lines as were in the hunk? I think you'd end up with confusing conflict markers. -Peff -- 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