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

[Junio C Hamano <gitster@pobox.com>]

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.