Re: Should notes handle replace commits?

[Mike Hommey <mh@glandium.org>]

On Fri, Jan 08, 2016 at 03:51:39PM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > 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.

It's not that different to me, but my point is that (almost) everything
about A redirects to Z, as you point out, _except_ notes.

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.

Mike