From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Mantas Mikulėnas" <grawity@gmail.com>,
git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [RFC/PATCH] hash-object doc: "git hash-object -w" can write invalid objects
Date: Fri, 22 Feb 2013 18:09:10 -0500 [thread overview]
Message-ID: <20130222230910.GD21579@sigill.intra.peff.net> (raw)
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
prev parent reply other threads:[~2013-02-22 23:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 22:30 Crashes while trying to show tag objects with bad timestamps Mantas Mikulėnas
2013-02-22 22:46 ` Jeff King
2013-02-22 22:53 ` Junio C Hamano
2013-02-22 23:04 ` Jeff King
2013-02-22 23:14 ` Mantas Mikulėnas
2013-02-25 18:21 ` Jeff King
2013-02-22 23:20 ` Junio C Hamano
2013-02-25 18:30 ` Jeff King
2013-02-25 18:38 ` [PATCH 1/4] handle malformed dates in ident lines Jeff King
2013-02-25 18:39 ` [PATCH/RFC 2/4] skip_prefix: return a non-const pointer Jeff King
2013-02-25 18:46 ` [PATCH 3/4] fsck: check "tagger" lines Jeff King
2013-02-25 18:50 ` [PATCH 4/4] cat-file: print tags raw for "cat-file -p" Jeff King
2013-02-25 19:33 ` Mantas Mikulėnas
2013-02-22 23:01 ` [RFC/PATCH] hash-object doc: "git hash-object -w" can write invalid objects Jonathan Nieder
2013-02-22 23:07 ` Junio C Hamano
2013-02-22 23:09 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130222230910.GD21579@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=grawity@gmail.com \
--cc=jrnieder@gmail.com \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).