Skip to content
Lore Protocol
Blog

Git Workflow Survival

Lore Protocol is designed to survive the real-world git workflows that break most metadata systems.

Rebase

Section titled “Rebase”

Lore-ids survive. Rebase rewrites commit hashes but preserves commit message content. Since all Lore references use Lore-id (in the message), not commit hashes, references remain valid after rebase.

No action needed.

Squash Merge

Section titled “Squash Merge”

Use lore squash before squash-merging to combine atoms:

Terminal window
# On feature branch, before squash merge:
lore squash main..HEAD > /tmp/squash-msg.txt
# Review/edit the message, then:
git checkout main
git merge --squash feature-branch
git commit -F /tmp/squash-msg.txt

Without lore squash, individual atoms are lost in the squash. The squashed atom preserves all knowledge by merging:

  • Array trailers (Constraint, Rejected, etc.): union of all values, deduplicated
  • Enum trailers (Confidence, Scope-risk, Reversibility): most conservative value
  • Internal references: dropped (atoms no longer exist separately)
  • External references: preserved

Teams that squash-merge should add lore squash to their merge workflow (can be enforced via CI).

Cherry-Pick

Section titled “Cherry-Pick”

Cherry-pick copies the commit message, including Lore-id. This creates a duplicate Lore-id across branches.

lore doctor detects this and reports it as an info-level finding (not an error — it’s expected for cherry-picks).

The CLI resolves duplicate Lore-ids by preferring the one on the current branch (reachable from HEAD).

Amend

Section titled “Amend”

git commit --amend preserves the Lore-id if the message is retained. If the message is rewritten, the author should preserve the Lore-id or generate a new one via lore commit.