Re: Should notes handle replace commits?

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 8, 2016, 23:51 UTC
Message-ID: <xmqqziwfzl2s.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160108214939.GA22801@glandium.org>

Mike Hommey <mh@glandium.org> writes:

Show 10 quoted lines

> On Fri, Jan 08, 2016 at 12:09:45PM -0800, Junio C Hamano wrote:
>> > So the question is, is this the behavior this should have?
>> 
>> The behaviour is a natural consequence of what graft and replace are
>> about (i.e. "telling Git what the parents of a commit are" vs
>> "telling Git what the contents of a commit are"), so the answer to
>> the "should" question is a resounding "yes".
>
> It's not only about contents, except for a very broad definition of
> contents that includes ancestry.

That is not broad at all. A Git commit knows about its parents in exactly the same way as it knows about its tree and its own log message. Hashing all of them together, without considering which part is "broad", gives us the content-addressible filesystem, which is "stupid content tracker", aka Git.

Perhaps you would see what is going on more clearly if you replace your "git log" with "git rev-list".

If your pre-graft/pre-replace histories were

	A (first)  <--- B (second)  <--- C (third)	master
	X (rFirst) <--- Y (rSecond) <--- Z (rThird)	old

then your "graft" tells Git "B's parent is Z, not A. If you run "rev-list master", it will give you "C B Z Y X". The discrepancy (relative to the true history) brought in by "grafting" is that nowhere in "cat-file commit B" you would find Z, even though "log" and "rev-list" pretends as if Z is a (and the) parent of B.

Your "replace" tells Git "A records what Z records". If you run "rev-list master", it will give you "C B A Y X".

A fake history made by "replace" does not have the same discrepancy as "grafting"; "cat-file commit B" names A as its parent, and asking what A is gives what actually is in Z, i.e. "cat-file commit A" shows what "cat-file commit Z" would give you. The discrepancy with the reality "replacing" gives you is that hashing what you got from "cat-file commit A" does not hash to A (it obviously has to hash to Z).

> From my POV, replace is more about
> "telling Git that this commit (and its parents) is really that one (and
> its parents)".

Your "POV" does not match reality; replace is about telling Git to give contents recorded for object Z when anybody asks the contents recorded for object A.