Carlos Martín Nieto <c...@elego.de> writes:
>> As packed-refs file is expected to be a text file, it is not
>> surprising to get an undefined result if the it ends with an
>> incomplete line.
> I guess that depends on what you mean by incomplete.
I used that word in the POSIX sense, i.e.
Unless the user edited the file, an incomplete line may indicate
that the file has been truncated when (or after) it was written, and
we have to suspect not just that the last "line" may have been
truncated (in this case, not having the full 40-hex object name),
but other records that should have been after that line were lost.
We may want to detect such corruption at runtime, at least at
strategic places; making it a hard runtime error will make it
difficult to use Git itself to recover from such an corruption
(e.g. you may have a healty mirror from which you can recover refs
with "fetch --mirror").
We should at least refrain from running repack/gc to make things
worse, for example.
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