Skip to content

Document and expose library API for safe venfork-config consumption#42

Draft
Copilot wants to merge 2 commits into
mainfrom
copilot/document-handle-force-push-semantics
Draft

Document and expose library API for safe venfork-config consumption#42
Copilot wants to merge 2 commits into
mainfrom
copilot/document-handle-force-push-semantics

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented May 7, 2026

Every config-mutating venfork command (stage --pr, pull-request, issue stage, issue pull, sync upstream-pr/<n>) force-pushes the venfork-config orphan branch. This causes a plain git fetch origin venfork-config:venfork-config to fail with non-fast-forward in any long-lived clone, silently leaving consumers with stale config state.

Changes

  • README.md — New "Consumers reading venfork-config directly" subsection under Concurrency documenting the force-push behaviour, the + refspec workaround, and the preferred library-helper approach.

  • src/lib.ts — New public library entry point re-exporting readVenforkConfigFromRepo and fetchVenforkConfig (both already avoid touching local refs internally) along with all config types.

  • package.json — Adds "exports": { ".": "./dist/lib.js" } and extends the build script to compile src/lib.ts alongside src/index.ts.

Usage

import { readVenforkConfigFromRepo, fetchVenforkConfig } from 'venfork';

// Long-lived clone — always gets current remote config, no local-ref management needed
const config = await readVenforkConfigFromRepo('/path/to/mirror-clone');

// No local clone — clones fresh to a temp dir
const config = await fetchVenforkConfig('github-org/private-mirror');

Both helpers fetch via FETCH_HEAD / a fresh temp clone, so non-fast-forward rejections cannot occur regardless of local ref state.

…nfork-config consumers

Agent-Logs-Url: https://github.com/cabljac/venfork/sessions/93a5a709-c27b-4a9b-bbc2-9f61016b4c44

Co-authored-by: cabljac <32874567+cabljac@users.noreply.github.com>
@cabljac cabljac requested a review from Copilot May 7, 2026 08:43
Copilot AI changed the title [WIP] Document force-push semantics of venfork-config for consumers Document and expose library API for safe venfork-config consumption May 7, 2026
Copilot finished work on behalf of cabljac May 7, 2026 08:43
Copilot AI requested a review from cabljac May 7, 2026 08:43
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR documents the intentional force-push/replace semantics of the venfork-config branch for downstream consumers, and introduces a small public library entry point so external tooling can read venfork config without having to manage git refspec edge-cases themselves.

Changes:

  • Added src/lib.ts as a public library API surface re-exporting readVenforkConfigFromRepo, fetchVenforkConfig, and related config types.
  • Expanded the README concurrency section with guidance for consumers fetching venfork-config, including preferred usage via the new library helpers.
  • Updated package.json to add an exports entry and build both src/index.ts and src/lib.ts into dist/.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File Description
src/lib.ts New public library entry point re-exporting config readers/types.
README.md New documentation describing consumer-facing fetch semantics and recommended helper usage.
package.json Adds package export mapping and builds the new library entry.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/lib.ts
Comment on lines +6 to +9
* `venfork-config` branch directly. Both helpers handle the
* force-push semantics of the config branch internally: they never
* update a local ref, so they are safe to call from a long-lived
* clone without ever hitting a non-fast-forward rejection.
Comment thread README.md
Comment on lines +515 to +530
Because every config-mutating command replaces (rather than appends to) the `venfork-config` branch tip, **a plain refspec fetch is rejected as non-fast-forward**:

```bash
# This FAILS after any venfork config update:
git fetch origin venfork-config:venfork-config
# ! [rejected] venfork-config -> venfork-config (non-fast-forward)
```

Tools that maintain a long-lived local clone and read the config branch must use a **forced refspec**:

```bash
# Force-update the local ref — safe because the branch is intentionally replaced:
git fetch origin +venfork-config:venfork-config
# or equivalently:
git fetch --force origin venfork-config:venfork-config
```
Comment thread README.md
git fetch --force origin venfork-config:venfork-config
```

**Preferred approach — use the venfork library helpers:** The `readVenforkConfigFromRepo` and `fetchVenforkConfig` functions exported from the `venfork` package handle this internally (they read via `FETCH_HEAD` / a fresh clone without touching any local ref), so you never hit the non-fast-forward edge case:
Comment thread package.json
Comment on lines +9 to 14
"exports": {
".": "./dist/lib.js"
},
"scripts": {
"build": "bun build ./src/index.ts --outdir ./dist --target node",
"build": "bun build ./src/index.ts ./src/lib.ts --outdir ./dist --target node",
"compile": "bun build ./src/index.ts --compile --outfile ./dist/venfork",
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Document/handle the force-push semantics of venfork-config for consumers

3 participants