Johannes Sixt <j...@kdbg.org> writes: >> Does the three-way merge machinery replay recorded resolution for >> such a binary file correctly (after your fix, that is)? > > Yes, it does. It recognizes the binary-ness and picks 'our' side. Only > then comes rerere_mem_getline into play.
Surely getline() needs to be fixed not to loop forever regardless of the binary-ness, but I was more worried about our additions of lines that satisfy is_cmarker(), counting of them in the callchain from handle_file() to handle_path() to decide if a path has already been resolved by the user, and recording of an resolution based on the return value of that callchain, all of which relies on the merged contents being textual and marked with the conflict marker. >>> diff --git a/rerere.c b/rerere.c >>> index a6a5cd5..4d940cd 100644 >>> --- a/rerere.c >>> +++ b/rerere.c >>> @@ -284,8 +284,10 @@ static int rerere_mem_getline(struct strbuf *sb, >>> struct rerere_io *io_) >>> strbuf_release(sb); >>> if (!io->input.len) >>> return -1; >>> - ep = strchrnul(io->input.buf, '\n'); >>> - if (*ep == '\n') >>> + ep = memchr(io->input.buf, '\n', io->input.len); >>> + if (!ep) >>> + ep = io->input.buf + io->input.len; >>> + else if (*ep == '\n') >>> ep++; >>> len = ep - io->input.buf; >>> strbuf_add(sb, io->input.buf, len); -- 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
