Am 02.04.2013 00:48, schrieb Junio C Hamano: > Johannes Sixt <j6t@xxxxxxxx> writes: > >> Using 'git rerere forget .' after a merge that involved binary files >> runs into an infinite loop if the binary file contains a zero byte. >> Replace a strchrnul by memchr because the former does not make progress >> as soon as the NUL is encountered. > > Hmph, thanks. > > Is it the right behaviour for rerere to even attempt to interfere > with a merge that involves binary files in the first place? Why not? And how could rerere tell the difference? It would have to do the same check for binary-ness as the merge driver before it even starts looking closer at the files. > 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. >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html