Mark Levedahl <mdl123@xxxxxxxxxxx> writes:
>>>
>>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?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html