v0.9.3 - Server creates the branch on its first push to a new branch

[0.9.3] - 2026-09-07

In plain terms: the previous release made deltix push put your work on
the right branch, but it still expected that branch to already exist on the
server. So the very first push of a brand-new branch — which git-style
workflows now create locally first, as of Deltix-Client v0.8.14 — stalled
and got rejected. Fixed: the server now behaves like git. If the branch you
push to does not exist yet, it creates it starting from the current
server state, then records your commits on it. The first push to a new
branch always works now, on both sides of the sync.

Fixed

• POST /repos/:repoId/push-commits no longer rejects the first push of a
  new branch. In runDoltCommitImport() the initial dolt checkout <branch> failed for a not-yet-existing branch (dolt addresses branches
  like tablespecs: error: tablespec 'x' did not match any table(s)), and
  the import aborted before any commit landed. It now distinguishes that
  case (extracted as isMissingBranchCheckoutError(), exported for
  testing) and heals it with dolt checkout -b <branch> — git push -u
  semantics: the branch is created from the current remote head and the
  pushed commits land on it. Any other checkout failure (e.g. uncommitted
  rows on the server repo) remains fatal and surfaces as before.
• Paired with Deltix-Client v0.8.14, which made branch creation
  local-first: the client creates branches locally and publishes them via
  push, so this branch-creation-on-push path is how the server becomes aware
  of new branches.

Tests

• New unit coverage for the isMissingBranchCheckoutError() predicate
  (missing-branch stderr → true; unrelated stderr → false).
• New real-dolt integration tests prove: a first push to a brand-new branch
  creates it (with * marking it active) and the commit lands on it, and
  that importing onto an already-existing branch is unchanged.
• 289 server unit tests pass; bun run lint clean (no errors).

v0.9.2 - push-commits honors the requested branch

[0.9.2] - 2026-09-04

In plain terms: even after fixing the client so it remembers which
branch you actually checked out, the server side of deltix push was still
always writing pushed commits onto its default branch (main) no matter
which branch the client said it was pushing from. If your project used a
different working branch (for example sync-develop-base), your pushes
were quietly landing on the wrong branch on the server — which, combined
with the client-side bug already fixed in Deltix-Client v0.8.8, is the full
root cause of the "branch disappeared" incident reported in issue #57.
Fixed: the server now checks out and imports onto the branch the client
actually asks for.

Fixed

• POST /repos/:repoId/push-commits now accepts an optional branch
  field in its request body and forwards it through
  CommitImportService.importCommits() to runDoltCommitImport(), which
  now runs dolt checkout <branch> before importing/committing — instead
  of always operating on whatever branch happened to be checked out
  server-side (effectively always main). Older clients that omit branch
  keep the previous behavior unchanged (backward compatible).
• Non-fast-forward detection (from) now compares against the head of
  the requested branch, not always main — runDoltBranchHead() was
  already branch-aware; it just was never called with anything but the
  default before.
• Paired fix with Deltix-Client v0.8.8, which stopped hardcoding main
  for pull/push/fetch on the client side and started sending the
  project's actual bound branch. Both sides needed the fix: the client fix
  alone would have made push send the right branch, but the server would
  have kept silently ignoring it and importing onto main anyway.

Tests

• New unit tests in commit-import.service.test.ts verify
  importCommits() forwards the client-requested branch to the commit
  runner (instead of relying on a hardcoded default) and that the
  fast-forward check reads the head of that same branch. Full existing
  unit (285 tests) and integration (231 tests, real Dolt binary + real
  HTTP via Hono) suites re-run clean with no regressions.

v0.9.1

Full Changelog: v0.9.0...v0.9.1

v0.9.0 - reject non-fast-forward pushes

[0.9.0] - 2026-09-04

In plain terms: Until now, when you pushed your saved work to a shared
repository, the server did not check whether anyone else had pushed newer
work in the meantime. That meant a push based on older data could quietly
overwrite or orphan someone else's newer commits, with no warning at all —
exactly the kind of silent data loss git protects you from. From now on, the
server behaves like git: if the remote "main" branch has advanced beyond the
version your push was based on, it refuses the push and tells you to pull
first. deltix push then shows a clear message instead of silently moving
ahead.

New

• Reject non-fast-forward pushes (mirrors git's default refusal). The
  push-commits endpoint now accepts an optional from — the remote head the
  client last pulled from. Before importing any commit, the server compares
  from against the current head of its main branch; if they don't match
  (because another dev pushed in the meantime), it responds 409 with a
  non-fast-forward code instead of importing the commits. This prevents a
  stale-base push from overwriting or orphaning a newer commit on the remote
  branch.
• Backwards-compatible protocol. A client that does not send from
  (older versions) is treated as before — the server skips the check, so
  existing clients and the push path keep working unchanged.

Fixed

• (None — this is a new safety guard, not a bug fix.)

Tests

• Unit suite: 92 passing tests in the versioning context, including new
  cases that a matching from is accepted, a mismatched from is rejected
  with NonFastForwardError (and no commits are imported), and an absent
  from is accepted for backwards compatibility.

v0.8.9

Full Changelog: v0.8.8...v0.8.9

v0.8.8

Full Changelog: v0.8.7...v0.8.8

v0.8.7

What's Changed

• docs: rewrite README for v0.8.6 by @SammyBytes in #22

Full Changelog: v0.8.6...v0.8.7

v0.8.6

v0.8.6: raise default refresh-token session TTL from 2 hours to 7 days. Combined with v0.7.10 access-token auto-refresh, active operators effectively stay logged in forever; inactive operators get booted after 7 days. Override DELTIX_SESSION_TTL_SECONDS for higher-security installations. 277 unit tests pass; lint clean.

v0.8.5

What's Changed

• fix(versioning): use dolt table import -r for row loading (handle empty strings in typed cols) by @SammyBytes in #20

Full Changelog: v0.8.4...v0.8.5

v0.8.4

What's Changed

• fix(versioning): import CommitImportError in push-commits router by @SammyBytes in #19

Full Changelog: v0.8.3...v0.8.4