Re: Possible regression in ref advertisement

["Carlos Martín Nieto" <cmn@elego.de>]

On Mon, 2013-02-25 at 13:16 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@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