From: Thomas Rast <trast@student.ethz.ch>
To: Junio C Hamano <gitster@pobox.com>
Cc: Robin Rosenberg <robin.rosenberg@dewire.com>,
Thomas Gummerer <t.gummerer@gmail.com>, <git@vger.kernel.org>,
<mhagger@alum.mit.edu>, <pclouds@gmail.com>,
<trast@student.ethz.ch>,
JGit Developers list <jgit-dev@eclipse.org>
Subject: Re: [GSoC] Designing a faster index format - Progress report week 13
Date: Sun, 22 Jul 2012 21:43:20 +0200 [thread overview]
Message-ID: <87629fvaxz.fsf@thomas.inf.ethz.ch> (raw)
In-Reply-To: <7vfw8jsk5o.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Sun, 22 Jul 2012 11:52:35 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>
>> A note on how JGit would work here. Java has none of the fields
>> that constitute statcrc. I guess we would write zero here when
>> creating new entries. Git could recognize that when checking status
>> and simply assume "clean" unless mtime or st_size says otherwise.
>
> Even though it may not be the end of the world, that is certainly
> bad. Recording the constituent fields separately without the statcrc
> microoptimization, thereby not shaving a handful of bytes per the
> index entry, is not the end of the world either in the same sense,
> which leads us to question the benefit we would be getting from such
> a change.
Hum, I'm a bit lost now.
What is the status quo? I take it JGit does not have any of ctime, dev,
ino etc., and either leaves the existing value or puts a 0. Which is
not different from either leaving the stat crc in place, or putting a 0.
Except that IIUC, putting a 0 in both cases means forcing a refresh once
C git comes along (or some other reader that knows about the fields).
So if we want to keep the safety net, a magic "I don't know" value would
indeed be a good idea. But I don't see how what Robin said constitutes
an argument in favor of splitting stat_crc into its fields again?
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2012-07-22 19:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-16 20:33 [GSoC] Designing a faster index format - Progress report week 13 Thomas Gummerer
2012-07-16 20:46 ` Junio C Hamano
2012-07-17 8:21 ` Thomas Gummerer
2012-07-17 8:24 ` Thomas Gummerer
2012-07-22 15:22 ` Robin Rosenberg
2012-07-22 18:52 ` Junio C Hamano
2012-07-22 19:43 ` Thomas Rast [this message]
2012-07-22 21:08 ` Junio C Hamano
2012-07-23 22:29 ` Robin Rosenberg
2012-07-24 11:54 ` Thomas Rast
2012-07-24 16:58 ` Junio C Hamano
2012-07-25 6:44 ` Thomas Rast
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=87629fvaxz.fsf@thomas.inf.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jgit-dev@eclipse.org \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.com \
--cc=robin.rosenberg@dewire.com \
--cc=t.gummerer@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.