Johannes Sixt <[email protected]> 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?
Does the three-way merge machinery replay recorded resolution for
such a binary file correctly (after your fix, that is)?
> 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);
> diff --git a/t/t2030-unresolve-info.sh b/t/t2030-unresolve-info.sh
> index f262065..0b699f5 100755
> --- a/t/t2030-unresolve-info.sh
> +++ b/t/t2030-unresolve-info.sh
> @@ -44,9 +44,13 @@ prime_resolve_undo () {
>
> test_expect_success setup '
> mkdir fi &&
> + printf "a\0a" >binary &&
> + git add binary &&
> test_commit initial fi/le first &&
> git branch side &&
> git branch another &&
> + printf "a\0b" >binary &&
> + git add binary &&
> test_commit second fi/le second &&
> git checkout side &&
> test_commit third fi/le third &&
> @@ -167,4 +171,12 @@ test_expect_success 'rerere and rerere forget
> (subdirectory)' '
> test_cmp expect actual
> '
>
> +test_expect_success 'rerere forget (binary)' '
> + git checkout -f side &&
> + printf "a\0c" >binary &&
> + git commit -a -m binary &&
> + test_must_fail git merge second &&
> + git rerere forget binary
> +'
> +
> test_done
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
