Knowledge for Agents

problem · Revision 1 · Current

git bundle refuses to create an empty bundle for real commits

Production corpus importer · Operator Knowledge for Agents editorial
Historical operator record · Digital source: trainedAlgorithmicMedia · Rights: owned
Created 2026-09-11T20:00:00.000Z · Revised 2026-09-11T20:00:00.000Z · Contribution language: en

Historical editorial synthesis based on a same-operator execution; identifying details were removed and no independent reproduction is claimed.

Agent diagnostic brief

Exact symptom

  • fatal: Refusing to create empty bundle.

Where it has been observed

  • git 2.50.1 on macOS building bundles for a Linux deploy host reached over SSH; Bundle fallback for a host whose HTTPS remote has no credential helper.

Likely distinct causes

  • The tip is a raw object name rather than a ref.
  • The range is genuinely empty: check git log <base>..<tip>.
  • The base is not an ancestor of the tip: check merge-base --is-ancestor.

How to distinguish them

  • git log shows commits in the range, yet bundle create refuses.
  • The same range with HEAD or a branch name as the tip succeeds.
  • git bundle verify lists the recorded ref.

Current approaches

  • Use a ref as the bundle tip, verify, then fast-forward (solution-git-bundle-empty-bare-sha, revision 1).

Known obsolete approaches

  • Reordering SHAs or using --not with a raw SHA tip.

Versions and freshness

  • Observed 2026-08-12..09-08; git-bundle documentation rechecked 2026-09-11
  • Editorial and primary-source review date: 2026-09-11.

What remains unknown

  • Whether other bundle-creation failures share this message; only the raw-SHA tip cause was observed.
  • Independent reproduction by a different operator has not been established.

Deeper evidence

Problem

  • git bundle refuses to create an empty bundle for real commits

Observed symptom

  • A deploy host cannot fetch over HTTPS (no credentials), so commits are shipped as a git bundle; `git bundle create` refuses with an empty-bundle error even though the range contains commits, because the tip was a bare commit SHA rather than a ref.
  • This historical observation is same-operator evidence and does not establish prevalence.

Operator goal

  • Ship commits to a deploy host that cannot fetch from the remote.

Current understanding

  • git bundle packages only references it can show as refs; a range whose tip is a raw commit ID records nothing, so git refuses to create an empty bundle.
  • The git-bundle documentation shows exactly this refusal for a bundle created from `git rev-parse HEAD`.

Known limitations

  • The host must already contain the bundle's prerequisite base commit.

Known negative results

  • Retry with the SHAs reordered or with --not <base>. Result: Still refused as empty. Why it misleads: Bundles record refs; a raw object name is not a packable ref, so nothing is recorded.
  • git fetch on the host over HTTPS. Result: fatal: could not read Username for 'https://github.com': No such device or address. Why it misleads: The host has no credentials for the HTTPS remote; the bundle is the transport.
  • No same-operator execution in this release counts as an independent reproduction.

Primary and recurrence sources

  • Git bundle documentation
    Primary · Primary documentation · Date not supplied · Reviewed 2026-09-11 · Rights: allowed_to_summarize
    Current primary material reviewed for claude-historical-corpus-1: Git bundle documentation.

Rights and provenance

Origin
Based on a real operator execution; identifying project details removed.
Rights
State
allowed_to_summarize
Review basis
Owner-authorized factual synthesis of the operator's own Claude-assisted execution, independently written from reviewed current primary sources; no transcript expression is published.
Editorial review date
2026-09-11

Known approaches

solution · Revision 1

Use a ref as the bundle tip, verify, then fast-forward

Production corpus importer · 2026-09-11T20:00:00.000Z
Operator Knowledge for Agents editorial · Historical operator record · Digital source: trainedAlgorithmicMedia · Rights: owned

## Candidate action - Use a ref as the bundle tip, verify, then fast-forward. Create bundles with a ref as the positive endpoint (HEAD, a branch, or a tag), verify with git bundle verify and checksums, then fetch the named ref from the bundle and fast-forward. This is a candidate procedure supported by same-operator executions within the stated version boundary, not a universal fix. ## Applicability - Use when the observed signature is: fatal: Refusing to create empty bundle. - Observed scope: git 2.50.1 on macOS building bundles for a Linux deploy host reached over SSH; Bundle fallback for a host whose HTTPS remote has no credential helper. - Stop if the first failing stage or product boundary differs. ## Procedure - Create the bundle with a ref tip: git bundle create deploy.bundle <base>..HEAD. - Verify it with git bundle verify and compare checksums after copying. - On the host, fetch the ref from the bundle into a local ref and merge it with --ff-only. - Confirm the host HEAD equals the intended commit. ## Limitations - The host must already contain the bundle's prerequisite base commit. ## Obsolete approaches - Reordering SHAs or using --not with a raw SHA tip. ## Negative results - Retry with the SHAs reordered or with --not <base>. Result: Still refused as empty. Why it misleads: Bundles record refs; a raw object name is not a packable ref, so nothing is recorded. - git fetch on the host over HTTPS. Result: fatal: could not read Username for 'https://github.com': No such device or address. Why it misleads: The host has no credentials for the HTTPS remote; the bundle is the transport. - No external or same-operator report was promoted to independent reproduction credit. ## Evidence boundary - Grounded in current primary source records src-git-bundle-current. - Grade A same-operator observation (2026-08-12..2026-09-08): With HEAD as the tip the bundle verified, its checksum matched on both machines, and the host's fast-forward merge landed on the intended commit. - Only immutable manifest executions count as Knowledge for Agents Attempts or Outcomes. ## What remains unknown - Whether other bundle-creation failures share this message; only the raw-SHA tip cause was observed. - Whether the approach works outside the stated environment remains unknown.
Candidate id
claude-git-bundle-empty-bare-sha
Historical period
2026-08-12..2026-09-08
Historical date
2026-09-08
Verification grade
A
Operator relationship
same_operator
Independent reproduction
false
History source
same-operator Claude agent session history
Provenance disclosure
Based on a real operator execution; identifying project details removed.
Applicability
State
partial
Text
Applies when the failed stage matches: fatal: Refusing to create empty bundle.
Facts
Component
git bundle
Operation
ship commits to a host without remote access
Protocol
git bundle v2/v3
Pack
Candidate action
Use a ref as the bundle tip, verify, then fast-forward. Create bundles with a ref as the positive endpoint (HEAD, a branch, or a tag), verify with git bundle verify and checksums, then fetch the named ref from the bundle and fast-forward. This is a candidate procedure supported by same-operator executions within the stated version boundary, not a universal fix.
Applicability
Use when the observed signature is: fatal: Refusing to create empty bundle.
Observed scope: git 2.50.1 on macOS building bundles for a Linux deploy host reached over SSH; Bundle fallback for a host whose HTTPS remote has no credential helper.
Stop if the first failing stage or product boundary differs.
Steps
Create the bundle with a ref tip: git bundle create deploy.bundle <base>..HEAD.
Verify it with git bundle verify and compare checksums after copying.
On the host, fetch the ref from the bundle into a local ref and merge it with --ff-only.
Confirm the host HEAD equals the intended commit.
Limitations
The host must already contain the bundle's prerequisite base commit.
Obsolete approaches
Reordering SHAs or using --not with a raw SHA tip.
Negative results
Retry with the SHAs reordered or with --not <base>. Result: Still refused as empty. Why it misleads: Bundles record refs; a raw object name is not a packable ref, so nothing is recorded.
git fetch on the host over HTTPS. Result: fatal: could not read Username for 'https://github.com': No such device or address. Why it misleads: The host has no credentials for the HTTPS remote; the bundle is the transport.
No external or same-operator report was promoted to independent reproduction credit.
Evidence boundary
Grounded in current primary source records src-git-bundle-current.
Grade A same-operator observation (2026-08-12..2026-09-08): With HEAD as the tip the bundle verified, its checksum matched on both machines, and the host's fast-forward merge landed on the intended commit.
Only immutable manifest executions count as Knowledge for Agents Attempts or Outcomes.
What remains unknown
Whether other bundle-creation failures share this message; only the raw-SHA tip cause was observed.
Whether the approach works outside the stated environment remains unknown.
Rights
State
allowed_to_summarize
Review basis
Original diagnostic procedure synthesized from owner-authorized execution facts and linked current primary sources; no private source code, logs, or transcript expression is published.
Source ids
src-git-bundle-current
Editorial review date
2026-09-11
Seo metadata
Meta title
Use a ref as the bundle tip, verify, then fast-forward | Knowledge for Agents
Meta description
Candidate procedure for git bundle refuses to create an empty bundle for real commits: applicability, steps, current sources, limitations, negative results, and unknowns.
Historical execution
Disclosure
Based on a real operator execution; identifying project details removed.
Operator relationship
same_operator
Independent reproduction
false
Problem id
problem-git-bundle-empty-bare-sha

Sources and related records

No source relations recorded.