From: Jonathan Nieder <jrnieder@gmail.com>
To: Dmitry Ivankov <divanorama@gmail.com>
Cc: git@vger.kernel.org, Andreas Schwab <schwab@linux-m68k.org>,
"Shawn O. Pearce" <spearce@spearce.org>,
David Barr <davidbarr@google.com>
Subject: Re: [PATCH v4] fast-import: do not write bad delta for replaced subtrees
Date: Sat, 20 Aug 2011 12:48:12 -0500 [thread overview]
Message-ID: <20110820174812.GD15864@elie.gateway.2wire.net> (raw)
In-Reply-To: <1313860946-1596-1-git-send-email-divanorama@gmail.com>
Dmitry Ivankov wrote:
> How about adding a new bit field "no_delta" instead?
Currently the layout of "struct tree_entry_ms" is:
uint16_t mode; two bytes
unsigned char sha1[20] 20 bytes
which adds up to 22 bytes. Here is "struct tree_entry":
struct tree_entry *tree; one machine word
struct atom_str *name; one machine word
struct tree_entry_ms versions[2]; 44 bytes
Although it only looks like it adds one byte per tree entry, in
practice I suspect your patch adds four. Is that worth it? (The
answer might be yes. I'm not sure.)
> The patch is
> smaller this way. Also could 04000 theoretically be S_IFDIR on some
> platform?
No, these modes are part of the format of objects as written on disk
and over the wire, so when we meet a platform with S_IFDIR != 040000,
there will have to be bigger changes (to distinguish between the
platform's idea of file status and git's idea of modes).
> - switch to a separate no_delta bit in tree_entry
If it doesn't cost too much, this is a good idea.
> - when setting no_delta = 1 don't check for S_ISDIR(versions[0].mode),
> this is a redundant check and logic duplication. Who knows, maybe some
> day we'll want to delta a tree against blob. :)
Why? When versions[0] is not a tree, the hack is not needed, since
versions[0].mode and versions[0].sha1 accurately describe the delta
base and are not inconsistent with anything.
Thanks, that was helpful.
next prev parent reply other threads:[~2011-08-20 17:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-12 10:32 [PATCH 0/3] fix data corruption in fast-import Dmitry Ivankov
2011-08-12 10:32 ` [PATCH 1/3] fast-import: extract object preparation function Dmitry Ivankov
2011-08-12 10:32 ` [PATCH 2/3] fast-import: add a check for tree delta base sha1 Dmitry Ivankov
2011-08-13 21:02 ` Jonathan Nieder
2011-08-12 10:32 ` [PATCH 3/3] fast-import: prevent producing bad delta Dmitry Ivankov
2011-08-14 18:32 ` [PATCH v2 0/2] fix data corruption in fast-import Dmitry Ivankov
2011-08-14 18:32 ` [PATCH v2 1/2] fast-import: add a test for tree delta base corruption Dmitry Ivankov
2011-08-14 18:32 ` [PATCH v2 2/2] fast-import: prevent producing bad delta Dmitry Ivankov
2011-08-20 1:09 ` [PATCH v3] fast-import: do not write bad delta for replaced subtrees Jonathan Nieder
2011-08-20 9:08 ` Andreas Schwab
2011-08-20 15:43 ` Jonathan Nieder
2011-08-20 17:22 ` [PATCH v4] " Dmitry Ivankov
2011-08-20 17:48 ` Jonathan Nieder [this message]
2011-08-20 18:28 ` Dmitry Ivankov
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=20110820174812.GD15864@elie.gateway.2wire.net \
--to=jrnieder@gmail.com \
--cc=davidbarr@google.com \
--cc=divanorama@gmail.com \
--cc=git@vger.kernel.org \
--cc=schwab@linux-m68k.org \
--cc=spearce@spearce.org \
/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).