From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Hommey Subject: Re: Should notes handle replace commits? Date: Sat, 9 Jan 2016 09:32:58 +0900 Message-ID: <20160109003258.GA31415@glandium.org> References: <20160108012830.GA2110@glandium.org> <20160108214939.GA22801@glandium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: git@vger.kernel.org To: Junio C Hamano X-From: git-owner@vger.kernel.org Sat Jan 09 01:33:34 2016 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aHhTI-000891-Su for gcvg-git-2@plane.gmane.org; Sat, 09 Jan 2016 01:33:33 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755871AbcAIAdL (ORCPT ); Fri, 8 Jan 2016 19:33:11 -0500 Received: from ns332406.ip-37-187-123.eu ([37.187.123.207]:38690 "EHLO glandium.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755354AbcAIAdK (ORCPT ); Fri, 8 Jan 2016 19:33:10 -0500 Received: from glandium by zenigata with local (Exim 4.86) (envelope-from ) id 1aHhSk-0008Bk-P6; Sat, 09 Jan 2016 09:32:58 +0900 Content-Disposition: inline In-Reply-To: X-GPG-Fingerprint: 182E 161D 1130 B9FC CD7D B167 E42A A04F A6AA 8C72 User-Agent: Mutt/1.5.24 (2015-08-30) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, Jan 08, 2016 at 04:13:02PM -0800, Junio C Hamano wrote: > Junio C Hamano 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