From: Jeff King <peff@peff.net>
Date: Fri, 22 Feb 2013 23:09:10 GMT
Subject: Re: [RFC/PATCH] hash-object doc: "git hash-object -w" can write invalid objects
Message-ID: <20130222230910.GD21579@sigill.intra.peff.net>
In-Reply-To: <20130222230132.GB4514@google.com>

On Fri, Feb 22, 2013 at 03:01:32PM -0800, Jonathan Nieder wrote:

> > Git doesn't handle the resulting tag objects nicely at all. For example,
> > running `git cat-file -p` on the new object outputs a really odd
> > timestamp "Thu Jun Thu Jan 1 00:16:09 1970 +0016" (I'm guessing it
> > parses the year as Unix time),
> 
> The usual rule is that with invalid objects (e.g. as detected by "git
> fsck"), any non-crash result is acceptable.  Garbage in, garbage out.

Agreed, though I think a more consistent garbage would be good (e.g.,
time=0, tz=0).

> I notice that git-hash-object(1) doesn't contain any reference to
> git-fsck(1).  How about something like this, to start?

I think it's a good change. Though note that this problem is not
discovered by fsck (which I think we should also change).

> Perhaps by default hash-object should automatically fsck the objects
> it is asked to create.

Not unreasonable. In this case, we also have git-mktag. It would be nice
if we could simply run the input through a type-specific sanity checker
(optional, I hope; I use hash-object often to craft test cases like this
:) ). The same need came up a month or two ago in a discussion of how to
use "git replace" safely. But I guess fsck after-the-fact is just
another form of the same solution.

-Peff