git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [IGNORETHIS/PATCH] Choosing the sha1 prefix of your commits
Date: Wed, 19 Oct 2011 23:57:17 -0700	[thread overview]
Message-ID: <7vr5289mlu.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20111020043448.GA7628@sigill.intra.peff.net> (Jeff King's message of "Thu, 20 Oct 2011 00:34:48 -0400")

Jeff King <peff@peff.net> writes:

> Agreed. Having hidden cruft makes birthday collision attacks easier (or
> it will, if sha1 ever gets broken to that point).  Unfortunately, there
> is a _ton_ of code which assumes that commit messages are
> NUL-terminated, as they always have been since e871b64 (2005-05-25).

I think that commit is irrelevant, as long as read_sha1_file() returns the
contents as <ptr,len> pair, which has been the case forever. It's just the
matter of propagating the length back up the callchain.

A naïve implementation to add "len" member to struct commit would increase
the size of the in-core commit object by sizeof(unsigned long), which we
may want to avoid. Traversals that care nothing but the topology of the
history would have to waste that memory and these things tend to add up
(8-byte ulong * 250k commits = 2MB).

Perhaps change the type of "buf" member in struct commit to a pointer to a
<ptr,len> pair, or something? Or perhaps a few megabytes wasted between
friends we do not care much about?

  reply	other threads:[~2011-10-20  6:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-19 18:03 [IGNORETHIS/PATCH] Choosing the sha1 prefix of your commits Ævar Arnfjörð Bjarmason
2011-10-19 19:01 ` Jeff King
2011-10-19 19:38   ` Jeff King
2011-10-20  2:51     ` Jeff King
2011-10-20  4:15       ` Kyle Moffett
2011-10-20  4:25         ` Jeff King
2011-10-20  4:27         ` Junio C Hamano
2011-10-20  4:32           ` Kyle Moffett
2011-10-24 20:47       ` Jeff King
2011-10-20  4:31     ` Junio C Hamano
2011-10-20  4:34       ` Jeff King
2011-10-20  6:57         ` Junio C Hamano [this message]
2011-10-20  7:13           ` Jeff King
2011-10-20 13:14             ` Ted Ts'o
2011-10-20 15:56               ` Jeff King
2011-10-25 22:35                 ` Drew Northup
2011-10-20 18:36             ` Re* " Junio C Hamano
2011-10-20 19:00               ` Jeff King
2011-10-20  7:27           ` Nguyen Thai Ngoc Duy
2011-10-20  9:14       ` Nguyen Thai Ngoc Duy
2011-10-20 15:44         ` Jeff King
2011-10-20  9:38   ` Mikael Magnusson
2011-10-20 13:44     ` Elijah Newren
2011-10-19 22:09 ` Jonathan Nieder

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=7vr5289mlu.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --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).