Re: Should notes handle replace commits?

[Mike Hommey <mh@glandium.org>]

On Fri, Jan 08, 2016 at 04:13:02PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > 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

git replace --graft does that automatically. But my contention is not
really about graft vs. replace. I should just have skipped that part,
it's largely irrelevant.

Mike