Back when
b4833a2c (rerere: Fix use of an empty strbuf.buf,
2007-09-26) was written, a freshly initialized empty strbuf
had NULL in its .buf member, with .len set to 0. The code this
patch touches in rerere.c was written to _fix_ the original code
that assumed that the .buf member is always pointing at a NUL-terminated
string, even for an empty string, which did not hold back then.
That changed in
b315c5c0 (strbuf change: be sure ->buf is never ever
NULL., 2007-09-27), and it has again become safe to assume that .buf
is never NULL, and .buf[0] has '\0' for an empty string (i.e., a
strbuf with its .len member set to 0).
A funny thing is, this piece of code has been moved around from
builtin-rerere.c to rerere.c and also adjusted for updates to the
hash function API over the years, but nobody bothered to question
if this special casing for an empty strbuf was still necessary:
b4833a2c62 (rerere: Fix use of an empty strbuf.buf, 2007-09-26)
5b2fd95606 (rerere: Separate libgit and builtin functions, 2008-07-09)
9126f0091f (fix openssl headers conflicting with custom SHA1 implementations, 2008-10-01)
c0f16f8e14 (rerere: factor out handle_conflict function, 2018-08-05)
0d7c419a94 (rerere: convert to use the_hash_algo, 2018-10-15)
0578f1e66a (global: adapt callers to use generic hash context helpers, 2025-01-31)
Finally get rid of the special casing that was unnecessary for the
last 19 years.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
strbuf_addbuf(out, &two);
rerere_strbuf_putconflict(out, '>', marker_size);
if (ctx) {
- git_hash_update(ctx, one.buf ?
- one.buf : "",
- one.len + 1);
- git_hash_update(ctx, two.buf ?
- two.buf : "",
- two.len + 1);
+ git_hash_update(ctx, one.buf, one.len + 1);
+ git_hash_update(ctx, two.buf, two.len + 1);
}
break;
} else if (hunk == RR_SIDE_1)