On 5/13/05, Chris Mason [off-list ref] wrote:
On Thursday 12 May 2005 00:36, Junio C Hamano wrote:
quoted
It appears to me that changes to the make_sure_we_have_it() ...
If we fetch the named object and it is a delta, the delta will either depend
on an object we already have or an object that we don't have. If we don't
have it, the pull should find it while pulling other commits we don't have.
Chris,
Doesn't that assume that the object referenced by the delta is
reachable from the commit being pulled. While that may be true in
practice, I don't think it is a logical certainty.
jon.
On Fri, 13 May 2005, Jon Seymour wrote:
On 5/13/05, Chris Mason [off-list ref] wrote:
quoted
On Thursday 12 May 2005 00:36, Junio C Hamano wrote:
quoted
It appears to me that changes to the make_sure_we_have_it() ...
If we fetch the named object and it is a delta, the delta will either depend
on an object we already have or an object that we don't have. If we don't
have it, the pull should find it while pulling other commits we don't have.
Chris,
Doesn't that assume that the object referenced by the delta is
reachable from the commit being pulled. While that may be true in
practice, I don't think it is a logical certainty.
1) If you happen to already have the referenced object in your local
repository then you're done.
2) If not you pull the referenced object from the remote repository,
repeat with #1 if it happens to be another delta object.
3) If the remote repository doesn't contain the object referenced by any
pulled delta object then that repository is inconsistent just like if
a blob object referenced by a tree object was missing. This
therefore should not happen. git-fsck-cache will flag broken delta
links soon.
Nicolas