Scenes to git and back

Export and import moves a scene as a folder: the scene at one moment, recorded against the commit it was taken from. Git wants the moments before it as well. Export a scene as a repository and every commit on the scene's chain becomes a git commit; import a repository and its commits replay onto the chain, oldest first. Nothing about the folder changes between the two pages; this one adds the history.

A repository is the folder with its history

daslab scene export scn_4jzQSSRcg2i8bCbO --git --out ./qbr
cd qbr && git log --oneline

f3a9c12 agent: revenue recomputed after segments changed
b71e004 mirko: trimmed the board questions to three
2c0d8aa import: provisioned from qbr-starter@a41f

The tree at each git commit is the scene's folder at that point in its chain. Author, message and time carry over; an agent's commit is authored as the agent, a person's as the person, an import as the import. Commits that changed nothing in the folder (a widget refreshing its numbers) are not written; git log reads as the scene's edits. git diff between two commits is the scene's diff between the same two, file by file. Run the same command again later and it appends what happened since. Without --git you get the folder alone, which is what Export and import describes.

Import replays commits, oldest first

daslab scene push ./qbr        # a repository: every commit not yet on the chain lands, in order

Pushing a repository is not one import; it is one import per commit that the scene has not seen, each landing on the chain with the git author, message and time. The scene's timeline begins where the repository's did, and the replay scrubber plays the repository's history like any other. The repository has to be a scene folder; a code repository is not one, and importing one is not what this does.

The two histories reference each other by hash and stay separate

Each scene commit that came from git records the git sha; each git commit that came from a scene records the scene commit in a trailer. That is the whole relationship, and it is also how a merge finds its base: the nearest commit both sides know is the common ancestor, and each commit after it merges against the one before, the same three-way rule a folder import uses against the commit it was exported from. A commit that is rebased before it is pushed arrives as a new sha with the same changes and merges clean. A scene is not a git remote: you do not git clone a scene, you clone the exported repository, and you do not git push to one, you daslab scene push. Keeping the two separate is what lets the scene's chain stay append-only and hash-linked while the repository does what repositories do, branches and rebases included. The merge rules on the way in are the importer's rules, stated once on Export and import; Commit chain has the mechanics of the chain itself.

A scene lives in git the way code does

daslab scene export scn_… --git --out ./qbr    # once
git checkout -b tighter-board-pack             # branch
$EDITOR notes/prep.md                          # edit
git commit -am "board pack: three questions"
daslab scene push ./qbr                        # your commit lands on the chain
daslab scene export scn_… --git --out ./qbr    # later: the agent's and your team's commits come back as git commits

Review in a pull request, bisect a regression in a view, tag a release of an integration, keep a scene in the same repository as the code it monitors. The scene does not know it is in git; it only sees commits arriving and leaving.

The public repo is where integrations are reviewed; the whitelist is where they go live

The open integrations live in one repository, daslabhq/asset-providers: the folder format, a validator, a local runner, and worked examples. Anyone can write an integration there and test it with no account:

bun cli/validate.ts providers/yourprovider
bun cli/run.ts providers/yourprovider yourprovider_search '{"query":"test"}' --credential api_key=…

Merging a pull request does not put code in front of Daslab users. A whitelist in the product pins the repository at one reviewed commit and names the integrations taken from it; only those are copied in, and the server refuses any folder that is present but not named. Kenko, Chatcone, Open-Meteo, Brave Search and Poly Haven are served from that repository today, at the commit the whitelist names. What makes a folder an integration is on Export and import.

Where to look next

Export and import for the folder and the importer's rules; Commit chain for what a scene commit is; the CLI for every flag. The repository is the reference: the spec and the examples there are the files the product loads.

Updated 2026-08-23