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@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html