On Wed, Dec 10, 2014 at 04:53:19AM -0500, Jeff King wrote:
Clarification: for-each-ref ignores the ref when the full line read
from packed-refs hits length 1024 (not when the refname itself hits
length 1024).
Yes, the problem is in read_packed_refs:
char refline[PATH_MAX];
...
while (fgets(refline, sizeof(refline), f)) {
...
}
This could be trivially converted to strbuf_getwholeline, but I am not
sure what else would break, or whether such a system would actually be
_usable_ with such long refs (e.g., would it break the first time you
I accidentally cut off the next line, but it was something like
...first time you actually tried writing to the ref).
Using fgets like this does shear lines, though. The next fgets call will
see the second half of the line. I think we are saved from doing
anything stupid by parse_ref_line, but it is mostly luck. So perhaps for
that reason the trivial conversion to strbuf is worth it, even if it
doesn't help any practical cases.
Here's a patch to do that. It still doesn't let you create long refs on
OS X, as we get caught up in the PATH_MAX found in git_path() and
friends. Still, I think it's a step in the right direction, and it fixes
the shearing issue.
Patches 2 and 3 are just follow-on cleanups.
[1/3]: read_packed_refs: use a strbuf for reading lines
[2/3]: read_packed_refs: pass strbuf to parse_ref_line
[3/3]: read_packed_refs: use skip_prefix instead of static array
I checked, and this miraculously does not conflict with any of the refs
work in pu. :)
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
