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