On 11/08/2011 12:55 AM, Jeff King wrote: > 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. I'm dealing with two codebases that have branched in the past, before any VCS was used, and now I'm tracking both separately with git. I'm trying to apply changes from one to the other with format-patch and git-am/apply. So yeah, no blob info. > 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. Personally, I wouldn't object to having both "computable" conflicts, and the .rej files for hunks that lack context, but I see how that would be very confusing. :) -Ori -- 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