feat(clone): report the remote repository's default branch in the clone result #838

New issue

Open

opened 2026-10-20 16:40:37 +00:00 by hexajon · 0 comments

hexajon commented

2026-10-20 16:40:37 +00:00

Owner

Summary

madtea clone and madt_clone do not report the remote repository's default branch. After the fix for #684, the clone result reports only what the clone checked out: branch (empty on a detached HEAD) and tag. The old defaultBranch field held the checked-out branch, not the remote default, so it was removed.

A clone result that also names the remote default would help a caller that cloned a tag or a feature branch and then wants to compare against the default. Nothing in madtea reads such a value today, so this is a feature, not a fix.

What git records after a clone

I probed this with git 2.47.3, against a source repo whose default branch is trunk, with a branch feature and a tag v1:

Clone shape	`refs/remotes/origin/HEAD`
plain	`origin/trunk`
`-b feature`	`origin/trunk`
`-b v1`	`origin/trunk`
`--depth 1`	`origin/trunk`
`--depth 1 -b feature`	missing
`--depth 1 -b v1`	missing (only `refs/tags/v1` exists)
`--bare`	missing (bare `HEAD` is `trunk`)
`--bare -b feature`	missing
`--bare -b v1`	missing

So no local ref gives the default in the single-branch and bare shapes. A full answer needs a second remote call there, for example git ls-remote --symref origin HEAD on the same transport and credential path as the clone, or the forge API's default_branch.

Acceptance criteria

The clone result carries the remote's default branch in a new field, in every clone shape in the table above, or leaves it empty with a notice that says why.
No clone shape falls back to a hardcoded branch name.
The lookup uses the clone's own transport and credential path, and adds no new one.
A test covers each clone shape in the table.

## Summary `madtea clone` and `madt_clone` do not report the remote repository's default branch. After the fix for #684, the clone result reports only what the clone checked out: `branch` (empty on a detached HEAD) and `tag`. The old `defaultBranch` field held the checked-out branch, not the remote default, so it was removed. A clone result that also names the remote default would help a caller that cloned a tag or a feature branch and then wants to compare against the default. Nothing in madtea reads such a value today, so this is a feature, not a fix. ## What git records after a clone I probed this with git 2.47.3, against a source repo whose default branch is `trunk`, with a branch `feature` and a tag `v1`: | Clone shape | `refs/remotes/origin/HEAD` | |---|---| | plain | `origin/trunk` | | `-b feature` | `origin/trunk` | | `-b v1` | `origin/trunk` | | `--depth 1` | `origin/trunk` | | `--depth 1 -b feature` | missing | | `--depth 1 -b v1` | missing (only `refs/tags/v1` exists) | | `--bare` | missing (bare `HEAD` is `trunk`) | | `--bare -b feature` | missing | | `--bare -b v1` | missing | So no local ref gives the default in the single-branch and bare shapes. A full answer needs a second remote call there, for example `git ls-remote --symref origin HEAD` on the same transport and credential path as the clone, or the forge API's `default_branch`. ## Acceptance criteria - The clone result carries the remote's default branch in a new field, in every clone shape in the table above, or leaves it empty with a notice that says why. - No clone shape falls back to a hardcoded branch name. - The lookup uses the clone's own transport and credential path, and adds no new one. - A test covers each clone shape in the table.

hexajon referenced this issue

2026-10-20 17:54:28 +00:00

fix!: clone reports the checked-out branch or tag, not a default branch (#684) #851

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#838

No description provided.

Rows
Columns