• The Agent-Scale Bottleneck

  • Autonomous coding with Claude shifted Anthropic's primary development bottleneck from writing code to human-scale developer infrastructure (source control, builds, and CI).
  • Between May and September 2026, code changes merged into Anthropic's monorepo jumped more than tenfold, from ~2,500 to over 30,000 merges per day.
  • To solve this, Anthropic built Scion, an in-house version control system, and migrated their entire monorepo away from Git in five months—alongside shipping a custom code review surface (Antique), code search, and a source control IAM system.

• Why Git Struggled at Scale

  • Git's decentralized design assumes offline-capable clients that hold complete repository copies, which clashes with Anthropic's workload of always-online AI agents and CI jobs.
  • Anthropic's monorepo reached nearly 100 GB of history on main (with a 25+ GB compressed working copy) and handles ~25 million CI checkouts per day—representing over 600 PB of daily Git traffic if fetched naively.
  • Standard large-monorepo workarounds—such as shallow clones, sparse checkouts, promisor remotes, blob storage seeds, and operating hundreds of internal Git mirrors—became operationally unsustainable as merge velocity accelerated and seeds rapidly fell behind main.

• Core Principles of Scion

  • Always-online clients & client-server asymmetry: Clients maintain only a bounded local object cache and delegate heavy computation (history, blame, diffs, merges, rebases, and commit creation) to an always-reachable server.
  • API-first source control: All queries are exposed via RPC APIs, allowing CI jobs, automated bisect/revert pipelines, and write workloads to query metadata, compute diffs, or land changes without ever materializing a local repository.
  • Horizontal scalability without full materialization: No server holds a complete materialized copy of the repo or generates Git-style packfiles, eliminating repository maintenance overhead.
  • Cheap, lock-free server-side commits: Commits, rebases, and merges happen directly on the server with costs proportional to the size of the change rather than the size of the repository. Global refs (branches/tags) are discouraged outside of main and release branches to avoid cross-server coordination bottlenecks.
  • Optional, sparse, and virtualized working copies: When disk files are needed, Scion defaults to sparse checkouts (fetching only requested directories) and virtualized checkouts (materializing files on demand).

• How Scion Works & Scales

  • Changesets & Derived Data: Instead of storing full tree pointers like Git, Scion's unit of work is a server-side changeset in a write-ahead log recording modified files relative to its first parent and content-addressed pointers to compressed blobs. Moving a ref is an isolated compare-and-swap on a single Cloud Spanner row.
  • Recursive Derived Data: Secondary indices (file blame, path history, commit graph skip lists, copy detection) are computed recursively from parent changesets, either eagerly or lazily, without exposing internal structures to clients.
  • Tiered Caching Architecture (scn client): Rather than negotiating what a client already has and generating dynamic packfiles, the scn client recursively requests missing immutable trees and blobs. Requests flow through a strictly tiered hierarchy—from a node-local scion-daemon (seeded from snapshots) to regional in-memory scion-cache servers, and finally to authoritative scion-servers backed by Spanner and cloud blob storage.
  • Performance Gains: Each cache tier achieves a >99% hit rate. Scion reduced source control infrastructure CPU and memory footprints by 200x compared to the prior Git mirror fleet and accelerated CI/research checkouts by two orders of magnitude (from minutes to seconds).

Hacker News Discussion

• Code Quality vs. Extreme Velocity

  • Commenters expressed skepticism about merging 30,000 AI-generated changes per day, questioning how Anthropic prevents "janky" or unmaintainable code from accumulating when human review cannot keep pace.
  • Several users pointed to performance and UX issues in Claude Code—such as high idle CPU usage, ~1 GB RAM overhead for a CLI wrapper, stuttering terminal spinner animations, and past accidental source leaks—as evidence that Anthropic prioritizes rapid feature iteration over traditional software polish.
  • Others defended this approach, arguing that in rapid AI development, shipping "good enough" working features quickly outweighs strict code perfection, especially under the assumption that future, more capable models will be able to refactor technical debt automatically.

• The Philosophy of Software Engineering

  • A major debate emerged around whether "engineering is the science of good enough" (optimizing for time, budget, and business constraints) versus the pursuit of deterministic excellence.
  • Critics of the "good enough" mindset argued that because computers are deterministic, accepting buggy, bloated software is a failure of craft, citing projects like SQLite and the Linux kernel as proof that high reliability and scale can coexist.
  • Pragmatists countered that all complex real-world systems (including hardware and the Linux kernel) contain bugs, and that aiming for zero defects outside of formally verified systems slows shipping velocity to an unacceptable degree.

• Economic Incentives & Token Consumption

  • Some participants noted a potential conflict of interest in "vibe-coded" workflows: when AI providers charge per token, bloated or poorly structured codebases that require constant AI-driven fixes and massive context windows inherently drive higher token revenue.
  • Others pushed back, noting that cost-per-token is trending downward and that breaking workflows into smaller, well-scoped agent steps significantly reduces drift and wasted tokens.

把知识管理变成代码管理是OKF最有实际价值的特性之一。现有的数据目录和知识库系统几乎无一例外地把知识锁在自己的数据库里，变更历史模糊，协作靠UI，审计靠日志。OKF把这些都换成了工程师已经熟悉的工具：git blame可以追溯谁修改了某个表的描述，PR可以让团队评审知识变更，diff可以清晰展示任何两个版本之间的差异。知识的可信度和代码一样，来自于透明的变更历史——这个属性在现有的知识管理工具里极度稀缺。

Using Git Worktrees in Claude Code

令人惊讶的是：这个项目不仅是一个浏览器自动化工具，还内置了一个使用AI生成分支名称的Git工作树管理器。它利用Google的Vertex AI和gemini-2.5-flash模型来自动创建有意义的分支名称，这展示了AI在开发工作流中的创新应用。

Commands for: - What Changes the Most - Who Built This - Where Do Bugs Cluster - Is This Project Accelerating or Dying - How Often Is the Team Firefighting

It says most are US, but lists none other. I think it should say Gitea Ltd as UK? bc of the Ltd? Gitea has been forked into Forgejo (and Codeberg). Gitea is open source, GitLab has an open source community version, but otherwise closed.

This article applies the same logic as David Eaves in [[The Path to a Sovereign Tech Stack is Via a Commodified Tech Stack]] to the 'software supply chain' here interpreted as: git forges, dependency intelligence layer on top of them, and package registries (like npm etc).

Summary: I Like GitLab

• Initial Adoption: The author originally chose GitLab because it offered free private repositories when GitHub still charged for them, leading to a long-term workflow integration.
• Integrated Container Registry: One of the most valued features is the built-in Docker registry, which eliminates the need for separate accounts, external access tokens, and concerns about Docker Hub pull limits.
• CI/CD Maturity: GitLab's "config as code" (.gitlab-ci.yml) is praised for being versioned with the repo and offering extensive documentation, though the sheer volume of options can be overwhelming.
• Runner Flexibility: While shared runners are reliable for free workloads, the author finds setting up custom runners on private VPS instances to be straightforward.
• Performance Issues: The web interface is consistently described as sluggish and slow compared to GitHub, creating "constant friction" during long sessions.
• Feature Bloat: GitLab attempts to be an all-in-one DevOps platform; while the author only uses about 10% of the features, they acknowledge the benefit of having advanced tools (like security scanning) available if needed.
• Workflow Split: The author uses GitLab as a "digital workshop" for private, messy experiments and reserves GitHub for public-facing collaboration and visibility.

Hacker News Discussion

• Corporate Shift & Quality: Several users noted that since its IPO, GitLab seems to prioritize "enterprise checklist" features and AI over fixing long-standing bugs and improving general UI polish.
• The "Sluggishness" Debate: A major point of discussion was GitLab's slow performance. Some attribute this to the "Ruby on Rails tax," though others pointed out that GitHub and Shopify also use Rails successfully, suggesting the issue lies in GitLab's specific architecture.
• Rise of Alternatives: Many commenters mentioned switching to Forgejo or Gitea for self-hosting, citing significantly lower resource requirements (up to 90% less) and near-instant page loads.
• The "80/20" Problem: Critics argued that GitLab often builds 80% of a feature to satisfy marketing requirements but leaves the remaining 20% of "polish" unfinished, leading to a "meme" of finding 5-year-old open bug reports for basic issues.
• Storage Exploits: There was a technical side-discussion about the 10GB project limit; users noted that because the limit often applies per-layer rather than per-registry, it can sometimes be bypassed for very large images.
• Website Appreciation: Many participants took a tangent to praise the blog's design, specifically its minimalist, terminal-like aesthetic and "markdown-as-markdown" presentation.

Deeper disclosure is possible: version-controlled authorship history (git-style) showing what human wrote vs. what AI generated.

The commit log becomes the disclosure - forensic, auditable, transparent. Not a vague "AI-assisted" disclaimer, but a traceable record of human-machine co-authorship.

Example: every commit with "Co-Authored-By: Claude Opus 4.5" plus commit messages explaining what was asked, proposed, reviewed, and approved.

This reframes the "crisis" as an opportunity for unprecedented transparency in collaborative authorship.

Some tips on her usage of Claude Code. - Put all your work in a folder next to the obsidian folder - to treat skills and commands like functions. Don't ever repeat them. - Install and use git locally to have a commit history. - On each step that you need to correct Claude code, tell it to write down directions or rules to avoid a mistake in the future. - circumvent public API liimits by changing the query slightly, or hit it in parallel

• Article argues pre-commit hooks are fundamentally broken due to running on working tree, not index, failing to catch unstaged changes.
• Hooks interfere with rebases, interactive commits, and external branches without hooks, requiring frequent --no-verify usage.
• Demonstrates issues via Rust fizzbuzz example: formatting fixes don't stage, existing unformatted code blocks commits, rebases fail unexpectedly.
• Recommends pre-push hooks instead: run on index, keep fast/reliable (no network/credentials), quiet, manual setup via docs.
• Additional pitfalls: slow/unreliable implementations, modifying commits, not running on stashes; prefers commits over stashes for branching.

Hacker News Discussion

• Users debate pre-commit vs. pre-push/CI: enforce in CI for reliability, use hooks to reduce churn but not guarantee (e.g., secrets in pre-push).
• Workflows vary: WIP commits common, rebase/squash before push; hooks break rebases needing full checkouts (e.g., cargo clippy).
• Editor integration preferred for formatting/linting; force consistency in teams but allow bypass for power users.
• Alternatives: git filters for formatting, jj run for future; personal setups run heavy local checks but optional for contributors.
• Defenses of pre-commit frameworks (speed, environments) countered by author; prefer CI for shared enforcement over local hooks.

This is the key bit for me. The reproducibility of the process itself will make the next time a lot more streamlined. I really like this article!

Me parece súper importante porque así se puede ver si alguien hizo cambios después de las indicaciones o si siguió las reglas que se dieron.

Un commit es una acción en sistemas de control de versiones (como Git) que guarda los cambios realizados en los archivos de un proyecto dentro del repositorio. Es como tomar una “foto” del estado actual del código para poder revisarlo, compartirlo o revertirlo en el futuro.

untrack file in git

git update-index --skip-worktree <files>

Meaning git config can include relative paths

maybefore, but check mainly AFTER indexing new files !

Recommendations for doing git rebase (see bullet points below annotation)

git bisect run ./calc.py 14 0 ← example of running git bisect automatically. * If the commit is good, then the command should return 0; * If the commit is bad, then the command should return anything between 1 and 127, inclusive, except 125; * If it is not possible to tell if this commit is good or bad, then it need to be ignored, and the command should return 125.

Git Bisect can be run manually or automatically

6 differen debugging tools

Excellent command to search in git history of a specific file!

if (!stat(worktree_git_path(wt, "rebase-apply"), &st)) { if (!stat(worktree_git_path(wt, "rebase-apply/applying"), &st)) { state->am_in_progress = 1; if (!stat(worktree_git_path(wt, "rebase-apply/patch"), &st) && !st.st_size) state->am_empty_patch = 1; } else { state->rebase_in_progress = 1; state->branch = get_branch(wt, "rebase-apply/head-name"); state->onto = get_branch(wt, "rebase-apply/onto"); } } else if (!stat(worktree_git_path(wt, "rebase-merge"), &st)) { if (!stat(worktree_git_path(wt, "rebase-merge/interactive"), &st)) state->rebase_interactive_in_progress = 1; else state->rebase_in_progress = 1; state->branch = get_branch(wt, "rebase-merge/head-name"); state->onto = get_branch(wt, "rebase-merge/onto"); } else return 0; return 1;

Resolved the problem I had where I mistakenly deleted this [local tracking branch]?

ls .git/refs/remotes/origin/HEAD ls: cannot access '.git/refs/remotes/origin/HEAD': No such file or directory

比较的是工作目录中当前文件和暂存区域快照之间的差异，若要查看已暂存的将要添加到下次提交里的内容，可以用 git diff --staged 命令

Jetbrains IDE 默认并不会开启暂存区功能，会自动都添加到暂存区

show commits of git as a tree

To show the last 2 commits use this! git log --oneline --graph --decorate --all HEAD~2..HEAD

configuration to make a shortcut to show commits of git as a tree

with emacs

This is an excellent resource for learing about Git integration with VS Code

https://codeberg.org/

Codeberg is a collaboration platform providing Git hosting and services for free and open source software, content and projects.

merge queue - new GitHub feature

后悔药，补充内容。

修改没有舞台去提交/修改没有放到舞台/修改没有放到暂存区

修改将被提交

标记资产，需要进行版本控制的内容。

初始化，获得/变成仓库/存储库

Where is the recomendation?

The tip of a branch deserved its own term.

git config --global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080

git config --global --add http.proxy http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT git config --global --add https.proxy http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT

export HTTPS_PROXY=http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT

3-way merge

conflict definition

• Git教程

Examples of Conventional Commits (see the block below)

Conventional Commits types: - feat - fix - docs - chore - refactor - tests - perf - styles - ci - build - revert

How probable is for some git hash-ids (some chars, not the full length) to collide:

• for a small project with ~100 commits:

  • 8 digits (32bits): 1/million
  • 7 digits (28bits): 1/54,000
  • 6 digits (24bits): 1/3,400

• for a big project: with ~10.000 commits:

  • 8 digits: 1/100
  • 7 digits: 1/6
  • 6 digits: ~1

As confirmed with the vecto repo, with these ipython commands: ```ipython

!git rev-list --all --count 14042 def collissions(k,N): ...: return 1 - e((-k(k-1)/(2N)))

collissions(14042, 16**6) 0.9971938358691735 !git rev-list --all | cut -c -6 | sort | uniq -cd 2 5af40d 2 6a6c62 2 914c24 2 d83979 2 e8060f

collissions(14042, 16**7) 0.3073608000674162 !git rev-list --all | cut -c -7 | sort | uniq -cd 2 e8060f9

collissions(14042, 16**8) 0.022691464724788335 !git rev-list --all | cut -c -8 | sort | uniq -cd <nothing> ```

Quick summary of rebase vs merge

```sparql PREFIX wd: http://www.wikidata.org/entity/ PREFIX gist: https://ontologies.semanticarts.com/gist/ PREFIX dcterms: http://purl.org/dc/terms/

SELECT DISTINCT ?commitTitle ?commitTime ?filename ?textLine WHERE {

?commit a wd:Q20058545 ; # it's a commit gist:hasPart ?part ; dcterms:subject ?commitSubject ; gist:atDateTime ?commitTime .

?commitSubject dcterms:title ?commitTitle .

?part gist:produces ?contiguousLines .

?contiguousLines gist:occursIn ?file ; http://example.com/containedTextContainer ?textContainer .

?file gist:name ?filename . ?textContainer ?line ?textLine .

FILTER(contains(?textLine,"music")) } ```

Location where git stash saves files

git clone 无法拉取被墙的 repo

Trouble shooting git add . issue.

Setting method one for Windows system working with others:

git config --global core.autocrlf true

comments for tag: undefined vs. null: Technically this is undefined (unset, !diff) vs. true (diff), but it's similar enough that don't need a separate tag just for that.

annotation meta: may need new tag: undefined/unset vs. null/set

Probably would be better to use:

git remote set-head origin -a