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

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 19 May 2009, Junio C Hamano wrote:
> 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.

Oh. I must have mistaken it with the protection in the opposite side:
git-fetch doesn't allow fetching arbitrary SHA-1 (arbitrary commits),
isn't it?

Side note: I wonder if any other DVCS has such shotgun of^W^W a feature ;-)

> > 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.
[cut]

Thanks for an explanation. So "refs/replace" is sanely transferrable
because it can be transferred using local reachability only (without
replacements turned on), isn't it?

As I understand the problem with replacement rules is that it cannot be
treated simply as 'extended SHA1' syntax; the replacements must be done
only for local operations, which probably means opt-in, and pushing it
down to the commands itself... well, that or marking commands as local
or remote...

-- 
Jakub Narebski
Poland