mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Jacob Vosmaer <>
Cc: Git Mailing List <>
Subject: Re: Feature-request: git-bundle --quiet
Date: Mon, 12 Aug 2019 12:08:35 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Aug 12, 2019 at 12:15:19PM +0200, Jacob Vosmaer wrote:

> This is a tangent, but relevant: how do we feel about the fact that
> 'git bundle create' does not perform CRC32 checks when copying data
> out of an existing packfile?
> See .
> I understand the rationale of "skip CRC32 when serving a fetch",
> although I have no clue how much we gain from skipping it. But "pack
> to stdout means fetch" isn't quite accurate, as it includes bundles.

I don't recall it being discussed in the past. I think you could argue
either way:

  - a bundle is just another form of object transfer, like a fetch, and
    so we don't need to be careful about bitrot. The receiver would
    notice it when it indexes the pack (as opposed to an on-disk repack,
    where we'll immediately delete the old copy, and really want to make
    sure we haven't just lost data).

  - because a bundle isn't interactive like a regular fetch, any bit
    errors may not be seen until much later when somebody reads the. At
    that point it may not be possible to go back to the original repo
    (in the extreme case of using a bundle as a backup, it may have been
    deleted entirely!).

Depending on the cost of those checks (and I really doubt they are all
_that_ expensive), it might make sense for bundles to err on the
conservative side and do them. And if they are expensive, it should
perhaps be made an option for people who know they are planning to store
the bundle for a long time without reading it[1].

I agree that linking "skip CRC32" to "pack to stdout" is a bit hacky. It
should be easy to add a new --check-crc32 option which defaults to
"!pack_to_stdout" if not specified.


[1] Of course bitrot in the original packfile is just one place this can
    go wrong. Depending how paranoid you want to be, it might be worth
    reading back the result before considering it a valid backup. That
    would catch some software bugs, as well as any bit corruption on the
    writing side. Doing a full index-pack is the most robust way there,
    but it's quite expensive. Just checking the SHA1 of the packfile
    itself would give pretty good protection against write errors,
    though you'd definitely want to couple it with CRC32 checks on the
    source (since Git would otherwise include the bad bits in its SHA1

      reply	other threads:[~2019-08-12 16:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06 19:19 Feature-request: git-bundle --quiet Robin H. Johnson
2019-08-08 10:42 ` Jeff King
2019-08-12 10:15   ` Jacob Vosmaer
2019-08-12 16:08     ` 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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

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).