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

From: Junio C Hamano <junkio@cox.net>
Date: Feb 16, 2007, 19:57 UTC
Message-ID: <7vhctl50zc.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <28763990.2658921171630394111.JavaMail.root@vms064.mailsrvcs.net>

Mark Levedahl <mdl123@verizon.net> writes:

Show 7 quoted lines

>>>
>>Also as Shawn pointed out, the script too heavily depends on GNU
>>tar.  Can we do something about it?
>
> Let me ponder, I'm sure I can do something. As I noted in
> another response, Cygwin won't let me reliably pipe the pack
> file through bash, so I'm forced to use some archiver.

Mark, how urgent do you want to have "bundle" in my tree? As I understand it, this came out of your working zip based implementation your group already use, so I am suspecting that you do not have urgent need to have a different one in git.git in a half-baked shape.

The reason I say this is because I very much in favor of the general idea of an archive file that can be used to sneakernet repository updates, but I find the current bundle-unbundle interface a bit awkward to integrate into the rest of the system.

Wouldn't it be nice if you can treat a bundle as just a different kind of git URL that you can "git fetch"?

	$ git fetch file.bdl 'refs/heads/*:refs/heads/*'

As the way I read the current implementation of git-unbundle is that it is designed to only overwrite (with fast-forward check not to lose changes from the target) all the refs in place. It does not, for example, allow extracting only one branch, nor storing the branch in a tracking branch by renaming. I think it would be nicer to change the external interface from the bundle subsystem to the calling scripts, so that it behaves closer to git-fetch-pack.

I haven't thought things through, but I think something like this would be sufficient:

	# create a bundle.
	$ git bundle --create v1.5.0..maint master next >file.bdl

	# you can view the tips of refs it contains.  This is
        # similar to "ls-remote" output.
	$ git bundle --list-heads file.bdl
        efa13f7b7ea1605deab3a6478fa0d0706c828170 refs/heads/maint
        af99711cd84c30a16450f73dbc21ba9f9f9803e6 refs/heads/master
        664e83a22b604fc5af1a84ddd48549b005cf4bc9 refs/heads/next

        # optionally allow checking if the pre-requisites of the
        # bundle are available.
	$ git bundle --verify file.bdl
	error: file.bdl depends on the following commits you lack
	in the repository:
        82bf92f9846326a743102e27fa9827422dddfada v1.5.0-564-g82bf92f
	4d462883de41190afd23672c8236361c61a9e6bd v1.5.0-34-g4d46288

	# extract the packfile part, run index-pack and report
        # the result the same way as git-fetch-pack
        $ git bundle --unbundle file.bdl
	pack	340e3faa26616ca8c38b369a6d323ecf7a34f4fb
        efa13f7b7ea1605deab3a6478fa0d0706c828170 refs/heads/maint
        af99711cd84c30a16450f73dbc21ba9f9f9803e6 refs/heads/master
        664e83a22b604fc5af1a84ddd48549b005cf4bc9 refs/heads/next

Then git-ls-remote can be taught about a bundle file and use the 'git bundle --list-heads'. Also, with something like this in your config:

	[remote "bundle"]
        	url = /home/me/tmp/file.bdl
                fetch = refs/heads/*:refs/remotes/origin/*

You can first sneakernet the bundle file to ~/tmp/file.bdl and then these commands:

	$ git ls-remote bundle
        $ git fetch bundle
	$ git pull bundle

would treat it as if it is talking with a remote side over the network.

Hmm?