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

From: Christian Couder <chriscool@tuxfamily.org>
Date: Aug 2, 2010, 07:42 UTC
Message-ID: <201008020942.58137.chriscool@tuxfamily.org>
In-Reply-To: <1280579802-8606-1-git-send-email-pclouds@gmail.com>

On Saturday 31 July 2010 14:36:42 Nguyễn Thái Ngọc Duy wrote:

Show 11 quoted lines

> Commit 0e87c36 (object: call "check_sha1_signature" with the
> replacement sha1) did this. I'm not sure if it's should be done this
> way.
> 
> With "repl" as the first argument to parse_object_buffer, the returned
> obj pointer will have the replaced SHA1 in obj->sha1, not the original
> one. I sort of expect that, no matter the object is replaced,
> obj->sha1 should stay the same.
> 
> This was observed by replacing commit tip. git log would show the
> replaced sha1, not the original one.

I am not sure I understand what you are saying. Do you mean that git log should show the original sha1 but the content of the replacement commit, instead of both the sha1 and the content of the replacement commit?

I just tested your patch and indeed with it it seems to me that the result shown by git log is not consistent, as for example the commit message is the one of the replacement commit but the commit sha1 is the one of the original commit.

The idea with replaced object was that as much as possible everything except some very low levels commands and transport commands should use the replacement objects (except if the --no-replace-objects option or NO_REPLACE_OBJECTS_ENVIRONMENT is used).

Could you explain why you need the object returned by parse_object_buffer to not have the replacement SHA1 in obj->sha1 when it is parsing the buffer from the replacement object?

Best regards, Christian.