rerere: update to modern representation of empty strbufs

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>

0 files changed, 0 insertions, 0 deletions