Re: [PATCH 2/3] commit: add function to unparse a commit and its parents
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- May 19, 2009, 07:48 UTC
- Message-ID
- <200905190948.09378.jnareb@gmail.com>
- In-Reply-To
- <7vfxf18szq.fsf@alter.siamese.dyndns.org>
On Tue, 19 May 2009, Junio C Hamano wrote:
Show 6 quoted lines
> 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 ;-)
Show 8 quoted lines
> > 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