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. http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_67 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
