Re: Should notes handle replace commits?

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 9, 2016, 01:04 UTC
Message-ID: <xmqqmvsfzhq4.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160109002510.GA30050@glandium.org>

Mike Hommey <mh@glandium.org> 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.