From: Junio C Hamano <gitster@pobox.com>
To: Kjetil Barvik <barvik@broadpark.no>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC v2 2/3] make USE_NSEC work as expected
Date: Fri, 20 Feb 2009 21:42:25 -0800 [thread overview]
Message-ID: <7vhc2os5vi.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <86mychifqj.fsf@broadpark.no> (Kjetil Barvik's message of "Fri, 20 Feb 2009 11:07:16 +0100")
Kjetil Barvik <barvik@broadpark.no> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> + ce->ce_ctime.sec = (unsigned int)st->st_ctime;
>>> + ce->ce_mtime.sec = (unsigned int)st->st_mtime;
>>> +#ifdef USE_NSEC
>>> + ce->ce_ctime.nsec = (unsigned int)st->st_ctim.tv_nsec;
>>> + ce->ce_mtime.nsec = (unsigned int)st->st_mtim.tv_nsec;
>>> +#else
>>> + ce->ce_ctime.nsec = 0;
>>> + ce->ce_mtime.nsec = 0;
>>> +#endif
>>
>> How does this affect a use case where the same index file used with two
>> instances of git (one compiled with and another without USE_NSEC)?
>
> OK, I admit that I was thinking safe here,...
It was not a veiled objection in the guise of a rhetoric question. I just
wanted to know what happens, when you have "/usr/bin/git" compiled without
NSEC and "/usr/local/bin/git" compiled with NSEC, and tried to use the two
interchangeably. A NSEC enabled one will leave nsec in the index entry,
and the normal one reads from the index file (truncating the nsec from
both file timestamp and on-disk index entries), and it is unclear what it
does to the racy-git algorithm. If there is no adverse effect, that is
great. Otherwise, even though the on-disk format might be compatible, we
need to somehow tell people not to use two gits on the same index file.
>>> diff --git a/unpack-trees.c b/unpack-trees.c
>>> index e547282..44714cc 100644
>>> --- a/unpack-trees.c
>>> +++ b/unpack-trees.c
>>> @@ -380,8 +380,12 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
>>>
>>> memset(&o->result, 0, sizeof(o->result));
>>> o->result.initialized = 1;
>>> - if (o->src_index)
>>> - o->result.timestamp = o->src_index->timestamp;
>>> + if (o->src_index) {
>>> + o->result.timestamp.sec = o->src_index->timestamp.sec;
>>> +#ifdef USE_NSEC
>>> + o->result.timestamp.nsec = o->src_index->timestamp.nsec;
>>> +#endif
>>> + }
>>
>> Do we need this hunk?
>
> Since timestamp is now a 'struct cache_time' member, I converted the
> usage of this if-test to be in line with the USE_NSEC usage.
My question was if it is wrong to leave this as "a->timestamp = b->timestamp"
which now becomes structure assignment. You would need to move extra 4
(or 8) bytes if you are not using NSEC, but this is not per index entry
but one assignment for the whole index file, so...
next prev parent reply other threads:[~2009-02-21 5:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 20:08 [PATCH/RFC v2 0/3] git checkout optimisation - part 3 Kjetil Barvik
2009-02-19 20:08 ` [PATCH/RFC v2 1/3] fix compile error when USE_NSEC is defined Kjetil Barvik
2009-02-19 20:08 ` [PATCH/RFC v2 2/3] make USE_NSEC work as expected Kjetil Barvik
2009-02-20 8:35 ` Junio C Hamano
2009-02-20 10:07 ` Kjetil Barvik
2009-02-21 5:42 ` Junio C Hamano [this message]
2009-02-19 20:08 ` [PATCH/RFC v2 3/3] verify_uptodate(): add ce_uptodate(ce) test Kjetil Barvik
2009-02-20 8:35 ` [PATCH/RFC v2 0/3] git checkout optimisation - part 3 Junio C Hamano
2009-02-20 9:03 ` Kjetil Barvik
2009-02-20 9:26 ` Sverre Rabbelier
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=7vhc2os5vi.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=barvik@broadpark.no \
--cc=git@vger.kernel.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 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.