Re: [PATCH] Add git-unbundle - unpack objects and references for disconnected transfer

From: Junio C Hamano <junkio@cox.net>
Date: Feb 16, 2007, 07:24 UTC
Message-ID: <7vk5yia7l7.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <45D54DB0.4090300@verizon.net>

Mark Levedahl <mdl123@verizon.net> writes:

> I'm not sure I follow the logic here. Assuming the object is a
> prerequisite of the bundle and exists, it will be reachable from an
> updated reference once the bundle is applied, no?

No. That's not the point. Yes, the object might be reachable, but you haven't proven that everything necessary to complete that object is already in the object store. We never trust existence of an object alone when doing an operation that updates a ref. Having unreferenced objects in the object store is a norm, but refs pointing at an object, some of whose prerequisites are missing, is a crime.

For example, suppose an earlier http-fetch found that the updated master should be at commit 'x', downloaded 'x', and you killed the process with ^C. It died without updating refs/remotes/origin/master, which is good. Then you have a bundle to unpack that has 'x' as a boundary.

You would start with a repository like this:

  ---o---o---o...-...-...-...x
             ^origin.

where 'x' is a dangling commit, '-' are ones that you do not have but you ought to have them in order for 'x' to be complete, and 'o' are complete commits. If the bundle boundary falls on the 'x' commit, you cannot say "I have all that are needed to complete this 'x'". You only have 'x' but still lack its prerequisites. That's what it means never to trust the mere existence of an object.

Linus's suggestion would make rev-list barf when 'x' cannot reach any existing ref, which is a good solution for this problem.

Also as Shawn pointed out, the script too heavily depends on GNU tar. Can we do something about it? Requiring GNU tar is probably fine if the script absolutely needs its extended features, as long as people have ways to tweak the command name in the script to point at their installed GNU tar (remember, some systems have GNU tar under different name such as "gtar").

Although if we require GNU tar we might be better off placing this under contrib/ not at the toplevel. I dunno.