git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Mantas Mikulėnas" <grawity@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Crashes while trying to show tag objects with bad timestamps
Date: Mon, 25 Feb 2013 13:21:01 -0500	[thread overview]
Message-ID: <20130225182101.GA13912@sigill.intra.peff.net> (raw)
In-Reply-To: <CAPWNY8UMkxvLPk2TxCz+BAat1sNXitjhv=yqcdY0yZ1OLjgd0w@mail.gmail.com>

On Sat, Feb 23, 2013 at 01:14:40AM +0200, Mantas Mikulėnas wrote:

> > Then I think it would make sense to allow the very specific no-date tag,
> > but not allow arbitrary crud. I wonder if there's an example in the
> > kernel or in git.git.
> 
> I couldn't find any such examples. However, I did find several tags
> with no "tagger" line at all: git.git has "v0.99" and linux.git has
> many such tags starting with "v2.6.11" ending with "v2.6.13-rc3".

Yes, I think Junio was mis-remembering the exact condition. It looks
like we added tagger lines in c818566 ([PATCH] Update tags to record who
made them, 2005-07-14), which pulls the identity straight from "git var
GIT_COMMITTER_IDENT". I double-checked to be sure that we included the
date stamp at that time, and we did.

When parsing such a tag, we put a "0" in the date field of the "struct
tag", and I suspect that is what caused the memory confusion.

So I think we are fine to fsck tagger lines as we do ordinary
author/committer ident lines; the only exception is that we should not
complain if they do not exist.

> It seems that `git cat-file -p` doesn't like such tags too – if there
> is no "tagger", it doesn't display *any* header lines. More bugs?

Yeah, I think we should just rid of that parser entirely. It is very
inconsistent with the pretty-printer used by "git show", as well as the
one used by "git for-each-ref", not to mention parse_tag (ugh, how many
tag parsers do we have?).

-Peff

  reply	other threads:[~2013-02-25 18:21 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 [this message]
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

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=20130225182101.GA13912@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=grawity@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 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 NNTP newsgroup(s).