On Mon, 2013-02-25 at 13:16 -0800, Junio C Hamano wrote: > 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
Huh, I must revise my POSIX. Sure, in that sense it's incomplete. > > 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"). Since the libgit2 parser seems to work with it, it's perfectly possible I did mess about with the file and then promptly forgot. An error would definitely not help here, but I do think a warning should be issued if the file isn't quite as it should be. It seems the parser can already detect this, so it could be as easy as adding a fprintf(stderr, "..."). > > We should at least refrain from running repack/gc to make things > worse, for example. > Sounds sensible, yep. cmn -- 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
