Hi, On Sat, 17 Jan 2009, Junio C Hamano wrote: > Subject: [PATCH] bundle: allow the same ref to be given more than once > > "git bundle create x master master" used to create a bundle that lists > the same branch (master) twice. Cloning from such a bundle resulted in > a needless warning "warning: Duplicated ref: refs/remotes/origin/master". > > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > bundle.c | 2 ++ > object.c | 19 +++++++++++++++++++ > object.h | 1 + > 3 files changed, 22 insertions(+), 0 deletions(-) Yes, that would be good. You have my ACK on that if you want. Another thing I am thinking about on and off: You cannot really use bundles as a replacement for regular transports (e.g. when you administrator does not let you ssh or git:// out, and you do not have an HTTP server available [*1*]). Suppose you have two branches, 'master' and 'side'. Now you make changes to 'master' and send the complete repository as a bundle to your friend. Now you delete the branch 'side', and send the next bundle (created with --all implying HEAD, and --since=$(stat -c %Y <first-bundle>)). Then your friend has no idea if 'side' was deleted or untouched. So I think we'd need some option for "create bundle" to list all specified refs, and if they have not really changed, their SHA-1s as prerequisites, too. Maybe "--full-bundle", or just "--full"? Another problem: suppose you have a branch, called 'private', that you excluded from your bundles. Now you happened to make changes to it, and by mistake, the branch gets included in the incremental bundle. No problem for you, as your friend lacks the prerequisites to reconstruct it. But unfortunately, your friend cannot even pull 'master' from it, because of our overzealous verification process which refuses all fetches when some prerequisites are missing locally, even if they are not even needed. This problem is much harder to solve, I think, and maybe we just want to leave it: as bundles are just fed into index-pack --fix-thin, which has no idea what objects can be skipped. Maybe there is no clean solution to that to begin with. Ciao, Dscho [*1*] When people are stuck behind such a stupidly restrictive firewall, often people come with "helpful" suggestions to use a VPN, or to publish your private repository, or get an external machine to HTTP proxy their connections. I find it outright mean to waste the time of people who already have a big problem. However, I believe that a mail based bundle exchange should be a relatively easy way out for those situations, once it works. -- 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
