Re: [PATCH 2/3] commit: add function to unparse a commit and its parents

From: Junio C Hamano <gitster@pobox.com>
Date: May 19, 2009, 07:14 UTC
Message-ID: <7vfxf18szq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <m3r5ylk347.fsf@localhost.localdomain>

Jakub Narebski <jnareb@gmail.com> writes:

> First, I have always thought that you cannot push arbitrary SHA-1
> (arbitrary commits) in git; you can only push via refs. Isn't it true?

No.

> Second, the "refs/replace" mechanism has the advantage over grafts
> that it is sanely transferrable. Whether "04a8c^2"^{replaced} exists
> on remote side depends on if other side has the same replacement, or
> if you push replacements in the same push.

The reason why replace mechanism could be cleaner than grafts is because reachability traversal and transfer do not obey replacements, and local ancestry traversal will if there are refs/replace entries.

So "git log" and friends will obey refs/replace/*, but between a repository that replaces a commit and another that doesn't, they will transfer history without replace entries getting in the way. Whatever 04a8c^2 resolves to with replacements, the _real_ history between that commit and whatever the tips of refs on the other side has is transferred, and that commit will update the 'master' branch on the other side.

If the other side sees it as the second parent of 04a8c is a different matter. If refs/replace hierarchy is shared between the repositories, it will; otherwise it won't. And the beauty of the replace mechanism is, unlike grafts, because object transfer will always be done using _real_ history, you can sanely sync refs/replace hierarchy between the repositories via push or fetch. During the push of the 04a8c^2 object, the other side does not have to worry about the presense/absense of replace that changes the interpretation of that notation on either end. The exact same underlying history is transferred with or without the replacement objects.