From: Andrew Harmon Date: Tue, 07 Oct 2025 21:11:43 GMT Subject: [BUG] git clone from bundle with --all does not fetch all refs Message-ID: # Problem with git bundle --all and git clone for air-gapped transfer to offline environments ## Description When creating a bundle using `git bundle create --all`, all refs including `refs/remotes/origin/*` are included in the bundle. However, when cloning from this bundle using `git clone`, these remote refs are not automatically fetched, making many branches inaccessible. ## Steps to Reproduce 1. In a repository with multiple branches and remote tracking branches (e.g., after cloning from GitLab/GitHub) 2. Create a bundle: `git bundle create repo.bundle --all` 3. Verify bundle contents: `git bundle list-heads repo.bundle` (shows both `refs/heads/*` and `refs/remotes/origin/*`) 4. Clone from bundle: `git clone repo.bundle cloned-repo` 5. Check available branches: `cd cloned-repo && git branch -a` ## Expected Behavior All refs included in the bundle (both `refs/heads/*` and `refs/remotes/origin/*`) should be accessible after cloning. Users should be able to see and checkout all branches that were in the original repository. ## Actual Behavior Only refs under `refs/heads/*` in the bundle become remote tracking branches. Refs stored as `refs/remotes/origin/*` in the bundle are not fetched during clone, making these branches inaccessible without manual intervention. ## Workaround After cloning, manually fetch the remote refs: ```bash git fetch origin 'refs/remotes/origin/*:refs/remotes/origin/*' ``` ## Impact This breaks the expected workflow for distributing complete repository snapshots via bundles (e.g., for offline environments). Users expect `git bundle --all` followed by `git clone` to preserve all branches. The `--all` flag documentation states it includes "all refs", but the cloning behavior does not match this expectation. This creates a surprising and unintuitive user experience when bundles are used for offline repository distribution. ## Environment [System Info] git version: git version 2.45.2.windows.1 cpu: x86_64 built from commit: 91d03cb2e4fbf6ad961ace739b8a646868cb154d sizeof-long: 4 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Windows 10.0 26100 compiler info: gnuc: 14.1 libc info: no libc information available $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe ## Suggested Fix One of the following approaches could address this issue: 1. **Automatic fetch during clone**: `git clone` should automatically fetch all refs present in a bundle, including `refs/remotes/origin/*`, OR 2. **Bundle creation remapping**: `git bundle create --all` should convert `refs/remotes/origin/*` to `refs/heads/*` so they're properly restored during clone, OR 3. **Documentation improvement**: Document this behavior clearly in `git-bundle` and `git-clone` documentation with the workaround, including a note that `--all` does not guarantee all refs will be available after cloning without additional steps. ## Additional Context This issue was discovered while preparing repository snapshots for developers working in offline/air-gapped environments. The workflow of `git bundle create --all` >> transfer >> `git clone` appears to be a complete solution but silently loses access to most branches. ********************************* Andrew Harmon aharmon@signalquest.com SignalQuest - precision microsensors 10 Water Street, Lebanon, NH, 03766 (603)-448-6266 *********************************