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:
parent
a8c5877412
commit
3b9c004a0c
1 changed files with 7 additions and 1 deletions
|
|
@ -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")?;
|
||||
|
|
|
|||
Loading…
Reference in a new issue