From 6faa31c1890e931c92d18a3c42ec57e0fd2503a8 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Mon, 17 Aug 2026 11:45:37 -0700 Subject: chore(todo): the installer also leaves the dotfiles clone unable to push Same two lines as the shallow-clone defect, found while pushing today. The dotfiles remote defaults to the public read-only endpoint, so a machine the installer built can fetch but never push. My other machine uses the ssh form, so the rebuilt one was the odd one out purely because the installer made it. That half is a decision rather than a fix, so the task loses its solo tag. The read-only default is right for anyone else installing this, who has no key on the server, and wrong for my own machines. The override already exists, so the only question is where my value lives. --- todo.org | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) (limited to 'todo.org') diff --git a/todo.org b/todo.org index 1ec7cf1..32eb9a2 100644 --- a/todo.org +++ b/todo.org @@ -236,7 +236,7 @@ unless you look) x rare edge case (one machine, specific conditions) = P2 = [#B]... except that this is a live, ongoing drain on a travelling machine rather than a latent defect, so it takes [#A] until the machine is back to normal. Re-grade to [#B] once resolved and the question is only prevention. -** TODO [#A] The installer shallow-clones the two repos I develop in :bug:velox:solo: +** TODO [#A] The installer clones my two working repos shallow and read-only :bug:velox: :PROPERTIES: :CREATED: [2026-08-17 Mon] :LAST_REVIEWED: 2026-08-17 @@ -263,16 +263,36 @@ gets =--depth 1= and org does not. The AUR build clones (=archsetup:855=, =:1673=, =:1677=) are correctly shallow and stay that way. Only the two user-repo sites change. -Repair on a machine already built: =git fetch --unshallow= in each repo. +*Second defect, same two lines, found 2026-08-17 while pushing:* the dotfiles +clone could not push at all. =archsetup:245= defaults =dotfiles_repo= to +=https://git.cjennings.net/dotfiles.git=, the public read-only endpoint, so +=git push= returned 403. Ratio uses =git@cjennings.net:dotfiles.git= and +archsetup's own clone uses the matching ssh form, so velox was the odd one out +purely because it was the machine rebuilt by the installer. Repointed velox's +remote and pushed. + +That half needs a decision rather than a fix, which is why this task is no +longer =:solo:=. The https default is *correct for a stranger* installing +archsetup, who has no ssh key on the server, and this repo is being prepared +for public release. It is wrong for my own machines, which need to push. The +override already exists (=DOTFILES_REPO=, documented in +=archsetup.conf.example=), so the question is only where my personal value +lives: a config the personal ISO bakes in, a post-install step, or a detection +that prefers ssh when a key is present. Craig's call. + +Repair on a machine already built: =git fetch --unshallow= in each repo, and +=git remote set-url origin git@cjennings.net:.git= for dotfiles. Grading: Major severity (two working repos silently missing their history on the machine I develop on, and it returns confidently wrong answers to history questions rather than failing) x every user every time (every fresh install, both daily drivers) = P1 = [#A]. -:solo: — the change is two lines plus tests in the existing -=tests/installer-steps/= shape, and it is verifiable locally by asserting the -clone command carries no =--depth= for these two repos. +Not :solo:. The depth half is (two lines plus tests in the existing +=tests/installer-steps/= shape, verifiable by asserting the clone command +carries no =--depth= for these two repos). The remote-URL half needs the +decision above, so the task as a whole waits on it. Split it in two if the +depth fix is wanted sooner. ** TODO [#B] post-rebuild-check needs a reference-host mode :feature:velox:solo: :PROPERTIES: :CREATED: [2026-08-17 Mon] -- cgit v1.2.3