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

From: Christian Couder <chriscool@tuxfamily.org>
Date: Aug 3, 2010, 05:00 UTC
Message-ID: <201008030700.40533.chriscool@tuxfamily.org>
In-Reply-To: <AANLkTin0eymuYFv_6hamDuan0TELogtCyW3Xwjm=pAwH@mail.gmail.com>

On Monday 02 August 2010 11:31:23 Nguyen Thai Ngoc Duy wrote:

Show 8 quoted lines

> 2010/8/2 Christian Couder <chriscool@tuxfamily.org>:
> > 
> > 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?
> 
> "original sha1, but the content of replacement commit", yes. Isn't
> that the intention of git-replace?

I think it's better if the sha1 is replaced too. This way we keep the link between the sha1 and the content.

And it's easier for the user to realize that we gave him a replacement object if we use the replacement sha1 as the user can more easily see that the sha1 changed.

Show 12 quoted lines

> > 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 consistency is already there. Suppose I want to replace commit A
> with B. Depends on what function I call to fetch "A", I get different
> object->sha1. (the content is always from B though).
> 
> 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. 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.

Best regards, Christian.