git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Carlos Martín Nieto" <cmn@elego.de>
Cc: git@vger.kernel.org, peff@peff.net
Subject: Re: Possible regression in ref advertisement
Date: Mon, 25 Feb 2013 12:07:14 -0800	[thread overview]
Message-ID: <7v1uc4ximl.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1361822092.30765.12.camel@centaur.cmartin.tk> ("Carlos Martín Nieto"'s message of "Mon, 25 Feb 2013 20:54:52 +0100")

Carlos Martín Nieto <cmn@elego.de> writes:

>> A shot in the dark, as I do not seem to be able to reproduce the issue
>> with anything that contains the commit.  Perhaps your .git/packed-refs
>> is corrupt?
>
> My packed-refs file did not end with LF. It seems it must or the parser
> won't consider the last tag in the file to have a peeled target and mine
> didn't. I don't how the ended up this way but it looks like there's is a
> bug in the parser (or does the format force you to have LF at the end?)

It is unclear what kind of corruption your packed-refs file had, as
there are multiple ways for a file not to "end with LF", but anyway.

As packed-refs file is expected to be a text file, it is not
surprising to get an undefined result if the it ends with an
incomplete line.

I do not offhand recall if we tolerate lines with CRLF endings; as
far as I know we do not _write_ CRLF out, and because we do not
expect people to muck directly with editor bypassing "pack-refs", I
would not be surprised if we didn't do anything special for people
who make the lines end with with CRLF the file, either.

I'd be more worried about the possibly lost entries after that
incomplete line (and also possibly truncated end part of the tagname
on the last, incomplete line).  Perhaps fsck should diagnose such an
anomaly as repository corruption?  Perhaps we should enhance the
file format a bit (right now, the first "capability" line should say
something like "# pack-refs with: peeled" to say it was created with
the version of pack-refs that can record peeled tags, but we can add
other capabilities to extend the format) to add checksums to detect
corruption?

  reply	other threads:[~2013-02-25 20:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-25 16:58 Possible regression in ref advertisement Carlos Martín Nieto
2013-02-25 18:31 ` Junio C Hamano
2013-02-25 19:18   ` Carlos Martín Nieto
2013-02-25 19:27     ` Junio C Hamano
2013-02-25 19:54       ` Carlos Martín Nieto
2013-02-25 20:07         ` Junio C Hamano [this message]
2013-02-25 20:35           ` Carlos Martín Nieto
2013-02-25 21:16             ` Junio C Hamano
2013-02-26 15:04               ` Carlos Martín Nieto
2013-02-26 15:46                 ` Junio C Hamano

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=7v1uc4ximl.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.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).