Re: Should notes handle replace commits?

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 9, 2016, 00:13 UTC
Message-ID: <xmqqvb73zk35.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqziwfzl2s.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 32 quoted lines

> 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.

To put it differently, what you did in your two examples with graft and replace are not equivalent. With graft, you told commit B that its parent is not commit A but commit Z. If you wanted to do the equivalent with replace, you would have replaced commit B with an otherwise identical commit B' that records Z as its parent. But you didn't; instead, you replaced commit A with Z.

And if you did the equivalent with "replace", your "git rev-list" would have shown "C B Z Y X" (instead of "C B A Y X"), and when "git log" showed the second commit, it would have shown the contents of B' _and_ because Git still thinks it is showing the original B, it would have shown the notes for B.

Something like this (totally untested) would let you replace B with an otherwise identical B' that has Z instead of A as its parent:

    $ Bprime=$(git cat-file commit master~ |
             sed -e "s/^parent .*/parent $(git rev-parse old)/" |
             git hash-object -w --stdin -t commit)

    $ git update-ref refs/replace/$(git rev-parse master~) $Bprime