fix(c0re): name the remote and branch on the knowledge pull

A bare `git pull --ff-only` merges whatever `branch.<current>.merge`
lists. A clone carrying more than one such entry aborts with "Cannot
fast-forward to multiple branches", which takes /knowledge out for every
agent on the hive - and the daemon neither writes that config nor can
see it, so the call worked only for as long as it happened to stay
clean.

Reproduced against two throwaway bare repos: duplicate merge entries
give that exact fatal, exit 128. A detached HEAD gives a different
error, and a missing tracking config does not reproduce at all - the
clone of an empty repo does write the tracking entry, so my first
explanation was wrong.

Naming origin and main makes the pull independent of local branch
config: a stray entry degrades to "the pull did not pick it up" instead
of breaking the shared mount. Does not explain how a second entry
appeared; nothing in this tree writes branch config.
This commit is contained in:
atlas 2026-08-14 19:50:56 +02:00
commit 3b9c004a0c

View file

@ -292,8 +292,14 @@ pub async fn pull(coord: &Coordinator) -> Result<()> {
Some(header) => crate::lifecycle::git_command_authed(header),
None => crate::lifecycle::git_command(),
};
// Remote and branch are named explicitly. A bare `git pull` merges
// whatever `branch.<current>.merge` lists, and a clone with more than one
// such entry aborts with "Cannot fast-forward to multiple branches" —
// taking /knowledge out across the hive over local config this daemon
// never writes and cannot see. `origin` exists by construction: the
// `remote set-url` above just set it.
let out = cmd
.args(["-C", LOCAL_DIR, "pull", "--ff-only"])
.args(["-C", LOCAL_DIR, "pull", "--ff-only", "origin", "main"])
.output()
.await
.context("git pull knowledge")?;