Re: [PATCH RFC] parse_object: pass on the original sha1, not the replaced one

From: Christian Couder <chriscool@tuxfamily.org>
Date: Aug 4, 2010, 11:58 UTC
Message-ID: <201008041358.13081.chriscool@tuxfamily.org>
In-Reply-To: <AANLkTikaPhV+SkzCJ+G3V39mS4FORELP34ePrPWbHFeV@mail.gmail.com>

On Tuesday 03 August 2010 08:01:32 Nguyen Thai Ngoc Duy wrote:

Show 10 quoted lines

> On Tue, Aug 3, 2010 at 3:00 PM, Christian Couder
> 
> <chriscool@tuxfamily.org> wrote:
> >> With parse_object(A), I get an object pointer whose sha1 is B.
> >> 
> >> With  lookup_commit(A), I get an object pointer whose sha1 is A.
> > 
> > Maybe there is a bug somewhere and you should get an object pointer whose
> > sha1 is B or maybe the content of the object that was inserted in the
> > lookup table should have been the content from A and not from B.

After having another look at that, I think the content of the object in the lookup table should be the content of A. It should be a bug if the object returned by lookup_commit(A) does not have the content of A.

Show 8 quoted lines

> > I will
> > try to have a deeper look at that, but it would help if you could give
> > an example of a command that triggers this behavior.
> 
> The following patch add "sha1" command. These commands give different sha1:
> 
> git sha1 `git rev-parse HEAD` `git rev-parse HEAD^` A
> git sha1 `git rev-parse HEAD` `git rev-parse HEAD^` B

Yes, but that does not mean that the content of the object returned by lookup_commit(A) is not the content of A.

Or do you have an example where the content of the object returned by lookup_commit(A) is not the content of A?

I mean that we should always be consistent by having objects with an obj->sha1 field corresponding to the content.

So yes we have:

> With parse_object(A), I get an object pointer whose sha1 is B.
>
> With  lookup_commit(A), I get an object pointer whose sha1 is A.

but it's not a problem, it's just the result from the fact that parse_object() (completely) replace objects and lookup_commit() does not.

Best regards, Christian.