From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Johan Herland <johan@herland.net>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
Date: Fri, 8 Jun 2007 00:38:20 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0706080034510.4046@racer.site> (raw)
In-Reply-To: <200706080128.48637.johan@herland.net>
Hi,
On Fri, 8 Jun 2007, Johan Herland wrote:
> On Friday 08 June 2007, Johannes Schindelin wrote:
> >
> > On Fri, 8 Jun 2007, Johan Herland wrote:
> >
> > > On Friday 08 June 2007, Johannes Schindelin wrote:
> > > >
> > > > The first empty line in a tag object separates the header from the
> > > > message. If the tag object has no empty line, do not crash, but
> > > > complain loudly instead.
> > >
> > > Aren't tag objects _required_ to have an empty line separating the
> > > headers from the body? At least I wrote the new tag code with that
> > > assumption in mind.
> >
> > Yes, evidently you did.
> >
> > But even then, isn't it always better to not rely on such assumptions, but
> > fail gracefully? The rest of Git's source code seems to be nicer to
> > failures as this one, IMHO.
>
> I agree that we should fail gracefully, and my code is clearly not doing
> that in this case. My bad.
>
> But the code should also detect invalid tag objects, and in this case I'm
> not yet convinced that the tag object causing the failure is in fact valid.
IT BROKE GIT IN A REPO THAT WAS PERFECTLY VALID BEFORE, AND I COULD NOT DO
ANYTHING AFTER THAT CHANGE.
Thank you very much again.
> If someone can convince me that the blank line after headers is optional,
> then I'll gladly fix the code.
Convincing enough?
> > > Could this be related to the "error: char103: premature end of data"
> > > you're seeing?
> >
> > Definitely. It breaks even _fetching_.
>
> Sorry again. Still, if I could get a look at the object that'd help me alot
> in debugging.
object f90084c7b53b1c2fb4606acafd84ef8a748a7d78
type commit
tag start
tagger me <me>
But I have to say that I am unlikely to review any fix you make, if that
fix is as unreadable as those mega long lines with funny spaces in the
middle of the line in that mega patch that unfortunately was already
applied in next.
I need a beer,
Dscho
next prev parent reply other threads:[~2007-06-07 23:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-07 22:40 [PATCH] fsck: do not crash on tag objects which do not contain an empty line Johannes Schindelin
2007-06-07 23:08 ` Johan Herland
2007-06-07 23:13 ` Johannes Schindelin
2007-06-07 23:28 ` Johan Herland
2007-06-07 23:38 ` Johannes Schindelin [this message]
2007-06-08 2:04 ` Nicolas Pitre
2007-06-08 2:14 ` Johan Herland
2007-06-08 5:17 ` Junio C Hamano
2007-06-08 5:30 ` Johannes Schindelin
2007-06-08 8:32 ` Andy Parkins
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=Pine.LNX.4.64.0706080034510.4046@racer.site \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
/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).