On 07/09, Stefan Beller wrote: > On Mon, Jul 9, 2018 at 6:09 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > > > On 7/8/2018 7:36 PM, brian m. carlson wrote: > > > 100 bytes is not sufficient to ensure we can write a commit message > > > buffer when using a 32-byte hash algorithm. Increase the buffer size to > > > ensure we have sufficient space. > > > > > > Signed-off-by: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> > > > --- > > > refs/files-backend.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/refs/files-backend.c b/refs/files-backend.c > > > index a9a066dcfb..252f835bae 100644 > > > --- a/refs/files-backend.c > > > +++ b/refs/files-backend.c > > > @@ -1587,7 +1587,7 @@ static int log_ref_write_fd(int fd, const struct object_id *old_oid, > > > char *logrec; > > > > > > msglen = msg ? strlen(msg) : 0; > > > - maxlen = strlen(committer) + msglen + 100; > > > + maxlen = strlen(committer) + msglen + 200; > > > logrec = xmalloc(maxlen); > > > len = xsnprintf(logrec, maxlen, "%s %s %s\n", > > > oid_to_hex(old_oid), > > > > nit: 100 is not enough anymore, but wasn't a very descriptive value. 200 > > may be enough now, but I'm not sure why. > > That line was touched in by Michael in 7bd9bcf372d (refs: split filesystem-based > refs code into a new file, 2015-11-09) and before that by Ronnie in 2c6207abbd6 > (refs.c: add a function to append a reflog entry to a fd, 2014-12-12) > and introduced > by Junio in 8ac65937d03 (Make sure we do not write bogus reflog > entries., 2007-01-26) > and it appears to me that 2*40 + 5 ought to be sufficient, but no > comments or commit > messages are found as to why we rather choose 100. Whats the reason for not using a strbuf here so that we don't have to play with magic numbers? -- Brandon Williams
