From: Jonathan Nieder <jrnieder@gmail.com>
To: "Mantas Mikulėnas" <grawity@gmail.com>
Cc: git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: [RFC/PATCH] hash-object doc: "git hash-object -w" can write invalid objects
Date: Fri, 22 Feb 2013 15:01:32 -0800 [thread overview]
Message-ID: <20130222230132.GB4514@google.com> (raw)
In-Reply-To: <kg8ri2$vjb$1@ger.gmane.org>
When using "hash-object -w" to create non-blob objects, it is
generally a good policy to run "git fsck" afterward to make sure the
resulting object is valid. Add a warning to the manpage.
While it at, gently nudge the user of "hash-object -w" toward
higher-level interfaces for creating or modifying trees, commits, and
tags.
Reported-by: Mantas Mikulėnas <grawity@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hi Mantas,
Mantas Mikulėnas wrote:
> When messing around with various repositories, I noticed that git 1.8
> (currently using 1.8.2.rc0.22.gb3600c3) has problems parsing tag objects
> that have invalid timestamps.
[...]
> 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.
> and `git show` outright crashes
> (backtrace included below.)
Probably worth fixing.
I notice that git-hash-object(1) doesn't contain any reference to
git-fsck(1). How about something like this, to start?
Perhaps by default hash-object should automatically fsck the objects
it is asked to create.
Thanks,
Jonathan
Documentation/git-hash-object.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index 02c1f12..8ed8c6e 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -30,6 +30,8 @@ OPTIONS
-w::
Actually write the object into the object database.
+ This does not check that the resulting object is valid;
+ for that, see linkgit:git-fsck[1].
--stdin::
Read the object from standard input instead of from a file.
@@ -53,6 +55,14 @@ OPTIONS
conversion. If the file is read from standard input then this
is always implied, unless the --path option is given.
+SEE ALSO
+--------
+linkgit:git-mktree[1],
+linkgit:git-commit-tree[1],
+linkgit:git-tag[1],
+linkgit:git-filter-branch[1],
+sha1sum(1)
+
GIT
---
Part of the linkgit:git[1] suite
--
1.8.1.4
next prev parent reply other threads:[~2013-02-22 23:02 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 ` Jonathan Nieder [this message]
2013-02-22 23:07 ` [RFC/PATCH] hash-object doc: "git hash-object -w" can write invalid objects Junio C Hamano
2013-02-22 23:09 ` Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130222230132.GB4514@google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=grawity@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.