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

From: Jakub Narebski <jnareb@gmail.com>
Date: May 19, 2009, 06:35 UTC
Message-ID: <m3r5ylk347.fsf@localhost.localdomain>
In-Reply-To: <7vws8d8y8i.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 17 quoted lines

> Christian Couder <chriscool@tuxfamily.org> writes:
> 
> > By the way, when you say that you suspect an attempt to replace an object 
> > that is directly listed on the command line would not work very well with 
> > the current replace series, is it related to the unparsing commit problem?
> 
> What I fear is something like this.
> 
> 	git push $there 04a8c^2:master
> 
> It would need to parse 04a8c to find its second parent and then start
> discussing what object to send with the other end.  "04a8c^2" is a direct
> user input and should mean the same commit as git show "04a8c^2" would
> give the user, so it obviously needs to obey the replace rules (making
> 04a8c parsed), but the object transfer should not look at replace at all
> (that's the whole point of not using the "graft hack" that cannot be
> sanely transferred to the other end).

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?

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.

Solution here could be to bail out and ask user to confirm whether other side has the same replacements... or something like that.

-- 
Jakub Narebski
Poland
ShadeHawk on #git