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

[Christian Couder <chriscool@tuxfamily.org>]

On Tuesday 03 August 2010 08:01:32 Nguyen Thai Ngoc Duy wrote:
> 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.

> > 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.