{"thread":{"id":"28528","subject":"git bundle unbundle and \"check-outable\" refs","startedAt":"2011-09-29T15:51:23Z","lastAt":"2011-09-29T17:20:43Z","messageCount":3,"participants":["Todd A. Jacobs","Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176494","messageId":"dec8c877-bd6e-4120-b045-87179d54abe2@i30g2000yqd.googlegroups.com","threadId":"28528","inReplyTo":null,"subject":"git bundle unbundle and \"check-outable\" refs","fromName":"Todd A. Jacobs","fromEmail":"nospam+listmail@codegnome.org","sentAt":"2011-09-29T15:51:23Z","receivedAt":"2011-09-29T15:51:23Z","isPatch":false,"sender":{"key":"nospam+listmail@codegnome.org","avatar":null},"body":"Never having needed git bundle before, I've recently been using it as\na sneakernet. In particular, I'm using bundles to work around\nlimitations of filesystem semantics on vfat and hpfs+ drives when\nshared between Linux and OS X systems. The systems are air-gapped, so\nsneakernet is essential.\n\nAt any rate, the issue I'm dealing with is that \"git bundle unbundle\"\nis sort of non-intuitive to deal with. It seems to add the commits\ndirectly to the local repository, but doesn't give me any of the\nbranch refs that I'm expecting from such an operation. In other words,\nif I bundle branch foo on machine A, then unbundle on machine B, I\nexpect to be able to \"git checkout foo\" and get on with life.\n\nInstead, it seems that I have to figure out what commits were\nunbundled, and create a new branch ref pointing to the head that I\nwant. I assume this is to prevent namespace collisions, but it seems\nreally, really cumbersome. Wouldn't it make more sense to include\nbranch names in the bundle, and simply prompt the user to rename refs\nthat conflict?\n\nI'm certainly open to other ideas of how to accomplish this workflow,\nand if there's an invocation to simplify this that I'm unaware of,\nplease advise. Otherwise, I really think the default behavior of the\nunbundle sub-command ought to be more intuitive.\n"},{"id":"176501","messageId":"7vsjnfthtk.fsf@alter.siamese.dyndns.org","threadId":"28528","inReplyTo":"dec8c877-bd6e-4120-b045-87179d54abe2@i30g2000yqd.googlegroups.com","subject":"Re: git bundle unbundle and \"check-outable\" refs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-29T16:49:11Z","receivedAt":"2011-09-29T16:49:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Todd A. Jacobs\" <nospam+listmail@codegnome.org> writes:\n\n> directly to the local repository, but doesn't give me any of the\n> branch refs that I'm expecting from such an operation. In other words,\n> if I bundle branch foo on machine A, then unbundle on machine B, I\n> expect to be able to \"git checkout foo\" and get on with life.\n\n$ git bundle -h\nusage: git bundle create <file> <git-rev-list args>\n   or: git bundle verify <file>\n   or: git bundle list-heads <file> [<refname>...]\n   or: git bundle unbundle <file> [<refname>...]\n\n$ git bundle list-heads /var/tmp/junk/foo.bundle\n632052641517de1a965c1f045b97d2eaa541b2e9 refs/heads/maint\n\n$ git fetch /var/tmp/junk/foo.bundle maint\nFrom /var/tmp/junk/foo.bundle\n * branch            maint      -> FETCH_HEAD\n\nor\n\n$ git fetch /var/tmp/junk/foo.bundle maint:bundle_head\n$ git log bundle_head\n"},{"id":"176503","messageId":"m3ty7vnu4g.fsf@localhost.localdomain","threadId":"28528","inReplyTo":"dec8c877-bd6e-4120-b045-87179d54abe2@i30g2000yqd.googlegroups.com","subject":"Re: git bundle unbundle and \"check-outable\" refs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-09-29T17:20:43Z","receivedAt":"2011-09-29T17:20:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Todd A. Jacobs\" <nospam+listmail@codegnome.org> writes:\n\n> Never having needed git bundle before, I've recently been using it as\n> a sneakernet. In particular, I'm using bundles to work around\n> limitations of filesystem semantics on vfat and hpfs+ drives when\n> shared between Linux and OS X systems. The systems are air-gapped, so\n> sneakernet is essential.\n> \n> At any rate, the issue I'm dealing with is that \"git bundle unbundle\"\n> is sort of non-intuitive to deal with. [...]\n\nI guess the fault is with \"git bundle\" documentation.\n\nThe \"Example\" section of git-bundle(1) manpage shows that you can use\npath to bundle in place of URL to repository in \"git clone\".  Actually\nyou can use path to bundle anywhere where URL or nickname of\nrepository is/can be used, i.e.:\n\n  git remote add <name> <bundle>\n  git fetch <bundle> [<refspec>...]\n  git pull <bundle>  [<refspec>...]\n\n  git ls-remote <bundle>\n\nHTH\n-- \nJakub Narębski\n"}]}