On Tue, Nov 08, 2011 at 09:52:26AM +0100, Bert Wesarg wrote: > On Mon, Nov 7, 2011 at 23:55, Jeff King <peff@xxxxxxxx> wrote: > > 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. > > GNU patch can produce conflict markers with the --merge option. Hmm. Yeah, it does work, but as I feared, it can produce pretty awful conflicts. Try this fairly straightforward setup (3 lines changed in the middle of a file): git init && seq 1 10 >file && git add file && git commit -m base && sed -i '3,5s/$/ master/' file && git commit -a -m master && git checkout -b other HEAD^ && sed -i '3,5s/$/ other/' file && git commit -a -m other You can see what a real merge looks like: git merge master && $EDITOR file which is: 1 2 <<<<<<< HEAD 3 other 4 other 5 other ======= 3 master 4 master 5 master >>>>>>> master 6 7 8 9 10 If you use "patch --merge", you get the same thing. Which is good. But now try it with 10 lines changed out of 100: rm -rf .git git init && seq 1 100 >file && git add file && git commit -m base && sed -i '50,60s/$/ master/' file && git commit -a -m master && git checkout -b other HEAD^ && sed -i '50,60s/$/ other/' file && git commit -a -m other Doing a merge will get you the same sensible results. But "patch --merge" produces: ... 45 46 <<<<<<< ======= 47 48 49 50 master ... 60 master 61 62 63 >>>>>>> 47 48 49 50 other 51 other 52 other 53 other ... which is not that helpful. Interestingly, I think it _should_ be able to do the same thing here as it did on the 3-line case. So I'm not sure why it doesn't. But there are even more complex cases, like say "other" had added new lines of new content at the beginning of the file, and messed up the context lines that the patch was using. So I think in the general case, you will end up with patches like the latter one. Just shoving the patch hunk into the file with an empty preimage section. And that can even still be useful, but you are relying on line counts then. If they're off, it's going ot be quite confusing. -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