On Fri, Jan 08, 2016 at 03:51:39PM -0800, Junio C Hamano wrote: > Mike Hommey <mh@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html