`pin init` writes `out: "static/vendor"` and the README's examples use `internal/web/static/vendor`. Almost every Go repo has a bare `vendor/` line in `.gitignore` (for `go mod vendor` output), which matches any directory named `vendor` at any depth. So a fresh `pin sync` in a Go project writes files that `git status` silently hides, and the next commit ships a `pin.lock` that references files not in the tree.
Hit this dogfooding in git-pkgs/proxy: `pin add diff2html ...` succeeded, the files landed in `internal/server/static/vendor/diff2html/`, and `git status` showed only `pin.yaml` and `pin.lock`.
Options:
- Rename the default to something that doesn't collide (`pinned`, `assets`, `third_party`).
- Have `pin sync` run `git check-ignore` on the output dir when inside a git repo and warn if it's ignored.
- Both.
The second is probably worth doing regardless of the default, since users who pick their own `out:` can hit the same trap with any ignored path.
`pin init` writes `out: "static/vendor"` and the README's examples use `internal/web/static/vendor`. Almost every Go repo has a bare `vendor/` line in `.gitignore` (for `go mod vendor` output), which matches any directory named `vendor` at any depth. So a fresh `pin sync` in a Go project writes files that `git status` silently hides, and the next commit ships a `pin.lock` that references files not in the tree.
Hit this dogfooding in git-pkgs/proxy: `pin add diff2html ...` succeeded, the files landed in `internal/server/static/vendor/diff2html/`, and `git status` showed only `pin.yaml` and `pin.lock`.
Options:
The second is probably worth doing regardless of the default, since users who pick their own `out:` can hit the same trap with any ignored path.