Mike Hommey <mh@xxxxxxxxxxxx> writes: > So while `cat-file commit A` gives you what `cat-file commit Z` would, > `notes show A` doesn't give you what `notes show Z` would. And that's > this "inconsistency" that bothers me. In any case, 'notes' being a way to add extra information to an existing object means that with your original "replace" that tells Git to keep A in the history (and give Z's contents when contents of A was asked), it is absolutely correct that notes for A is shown. It would make no sense if notes for Z "followed", because as long as Git is concerned, you told Git to show A when your "git log master" followed the history down thru B to its parent, which you did not rewrite to be Z but kept to be A. With the approach to replace B with B' that has Z as its parent, when "git log master" follows the history down thru C to its parent, Git thinks it is showing B but reads B', and finds out its parent is Z and goes down to Z, and notes for these two commits B and Z (not B' and Z) would be shown; there is no need to "follow". The true source of your confusion, I think, is that there is a misunderstanding of what "replace A with Z" does. It is not "whenever somebody refers to A, pretend as if it is referring to Z". If that _were_ the case, then I'd agree that "whenever somebody else asks notes attached to A, pretend as if notes attached to Z were asked" might make sense, but that does not match the reality. It is not graft vs replace. It is about what you replace with what other thing: "replace" is a content replacement mechanism, not identity replacement mechanism. -- 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