On Thu, Mar 13, 2008 at 11:00:23AM -0700, Junio C Hamano wrote:
> > index c607aad..e4a1dc1 100644
> > --- a/builtin-rerere.c
> > +++ b/builtin-rerere.c
> > @@ -58,7 +58,8 @@ static int write_rr(struct path_list *rr, int out_fd)
> > int length = strlen(path) + 1;
> > if (write_in_full(out_fd, rr->items[i].util, 40) != 40 ||
> > write_in_full(out_fd, "\t", 1) != 1 ||
> > - write_in_full(out_fd, path, length) != length)
> > + write_in_full(out_fd, path, length) != length ||
> > + write_in_full(out_fd, "\n", 1) != 1)
> > die("unable to write rerere record");
> > }
> > if (commit_lock_file(&write_lock) != 0)
>
> No, check 3f43d72392b6c0477debd7edbd49bae9b7f41e60^:git-rerere.perl; the
> records in this file are supposed to be NUL terminated (the paths are
> allowed to have LF in them).
Ah, OK. And it actually does do that correctly ("length = strlen(path) +
1"). So I think there isn't a bug there in rerere.
But if it's NUL-terminated, then using sed _definitely_ isn't portable
here. cut does work on Solaris in this case, but that might or might not
be portable to other systems with similar NUL problems. I'm not sure
what is the best route. We really just want to grab the sha1 from the
beginning of the first line. dd count=40? :)
-Peff
--
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
