On Monday 02 August 2010 11:31:23 Nguyen Thai Ngoc Duy wrote: > 2010/8/2 Christian Couder <chriscool@xxxxxxxxxxxxx>: > > > > 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. > > 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. -- 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