P
←→

Lore execution model

date: 2026-06-16
author: Peterino

Mental model

It’s like perforce but with individually adressable objects and more stuff you can do locally.

  • Central server based but with local edit/stage/commit flow like Git.
  • The server owns canonical branch latest pointers and durable storage.
  • Your working tree owns edits, dirty flags, staged paths, commit pushes to server, push merges on server.
  • lore push publishes by moving the remote branch latest pointer. (heavy lifting is done by commit)
lore status --scan
lore stage --scan .
lore commit "Describe the change"
lore push
lore sync

What commit does

lore commit creates a revision from staged paths and moves your local branch latest to it. It does not publish the remote branch latest.

Staging is like p4 checkout. marks a file as something we will commit when we run commit. it doesn’t track frozen bytes like git

You can commit locally with lore --local commit and lore --offline commit

The server may receive content and revision data during commit, but other users still do not see your branch move until lore push.

lore commit "WIP"
# local branch latest moved
# remote branch latest unchanged

lore push
# remote branch latest moved if accepted

Perforce mapping

The biggest translation: p4 submit records and publishes together. Lore splits that into lore commit for the local revision and lore push for the remote branch update.

Perforce Lore
p4 reconcile lore status --scan or lore stage --scan .
p4 submit lore commit, then lore push
p4 sync lore sync
Open for edit Edit normally; Lore reads the filesystem.

Locks

  • lore lock acquire path/to/file records a server-side claim.
  • lore lock status path/to/file or lore lock query shows who has it.
  • lore lock release path/to/file clears the claim when the edit is done.

unlike p4 locks are advisory.

Shelves

There is no direct p4 shelve equivalent. A Perforce shelf is a server-side snapshot of pending work; Lore does not keep a separate shelf namespace. Use the normal revision model instead.

  • Local WIP: leave paths dirty or staged.
  • Private checkpoint: lore --local commit "WIP".
  • Shareable WIP: commit on a branch and push it.
lore branch create wip/material-pass
lore branch switch wip/material-pass
lore stage --scan Content/Materials
lore commit "WIP material pass"
lore push wip/material-pass

Git mapping

Git Lore
git status lore status --scan
git add lore stage
git commit lore commit
git push lore push
git pull lore sync

Branches

A branch is a named latest pointer. Commit moves the local pointer. Push asks the server to move the remote pointer.

This is why local and remote branch state can differ. After lore commit, your branch can be ahead locally. After lore sync, your working tree catches up to remote branch movement.

main       -> A
feature-x  -> A

# commit on feature-x
main       -> A
feature-x  -> B

Stores

There are two stores, mentally for me, I’m kind of mapping them between vcs based usage like p4 and using it like an object storage.

  • Immutable store: content-addressed fragments, trees, metadata, and revisions.
  • Mutable store: branch names, latest pointers, and local instance state.

Commit writes immutable data and moves a local mutable pointer. Push makes remote data complete and moves the server pointer.

Generated from local Lore docs and CLI behavior.

← Previous Lore CLI cheat sheet Next → Lore auth guide