Re: Possible regression in ref advertisement

From: Carlos Martín Nieto <cmn@elego.de>
Date: Feb 26, 2013, 15:04 UTC
Message-ID: <1361891069.9005.11.camel@flaca.cmartin.tk>
In-Reply-To: <7vfw0kt7qc.fsf@alter.siamese.dyndns.org>

On Mon, 2013-02-25 at 13:16 -0800, Junio C Hamano wrote:

Show 11 quoted lines

> 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.

Show 12 quoted lines

> 
> 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