git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Pieter de Bie <pdebie@ai.rug.nl>, Git Mailinglist <git@vger.kernel.org>
Subject: Re: [PATCH v2] builtin-fast-export: Add importing and exporting of revision marks
Date: Sat, 07 Jun 2008 09:37:52 -0700	[thread overview]
Message-ID: <7vy75hnqu7.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0806071612460.1783@racer> (Johannes Schindelin's message of "Sat, 7 Jun 2008 16:19:35 +0100 (BST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Okay, I looked again, and indeed, you _copied_ it.  Instead of using the 
> functions mark_object() and get_object_mark() which are there only to be 
> used by you.
>
> So please fix.
>
>> >Even if that is the case, doesn't "(uint32_t *)deco->decoration - 
>> >(uint32_t *)NULL" mean the value range for deco->decoration is 
>> >one-fourth of U32?
>
> It is.  But since every object needs already at least 20 bytes, and we do 
> not even have the complete address space to put objects into, and we do 
> not plan to support 64-bit only repositories, I think we are fine.

Oh, I was not complaining about the one-fourthness.  I was wondering why
"(uint32_t *)", which makes it look like the type itself has very deep
meaning for this computation, was used, instead of "(char *)" or something
that makes it much clearer that what could be pointed at by the pointer
does not matter and you are only using them as fake integers.  If there is
such a deep meaning, it needs documented, and if there isn't then probably
the use of (uint32_t *) should also be fixed.

  reply	other threads:[~2008-06-07 16:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-04 20:55 [PATCH] builtin-fast-export: Add importing and exporting of revision marks Pieter de Bie
2008-06-05  0:00 ` Johannes Schindelin
2008-06-05 10:46   ` Pieter de Bie
2008-06-05 10:52     ` [PATCH v2] " Pieter de Bie
2008-06-05 13:35       ` Johannes Schindelin
2008-06-06 23:09       ` Junio C Hamano
2008-06-07 13:06         ` Pieter de Bie
2008-06-07 15:19           ` Johannes Schindelin
2008-06-07 16:37             ` Junio C Hamano [this message]
2008-06-11 19:45               ` Johannes Schindelin
2008-06-07 13:25       ` [PATCH] Documentation/fast-export: Document --import-marks and --export-marks options Pieter de Bie
2008-06-07 15:20         ` Johannes Schindelin
2008-06-10  6:47         ` Junio C Hamano
2008-06-11 11:17           ` [PATCH v3] builtin-fast-export: Add importing and exporting of revision marks Pieter de Bie
2008-06-11 11:24             ` Pieter de Bie
2008-06-11 18:45             ` Johannes Schindelin
2008-06-11 21:43             ` Junio C Hamano
2008-06-05 13:31     ` [PATCH] " Johannes Schindelin

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=7vy75hnqu7.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=pdebie@ai.rug.nl \
    /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).