Pre-release binaries for testing

Built from commit 80e2009 on feat/sapling-scm-support. Download for your platform:

Binaries are attached as assets on the v0.0.0-sapling-rc1 pre-release.

Quick install

# macOS (Apple Silicon)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc1/crit-darwin-arm64 -o crit && chmod +x crit

# Linux (x86_64)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc1/crit-linux-amd64 -o crit && chmod +x crit

Or build from source:

go install github.com/tomasz-tomczyk/crit@feat/sapling-scm-support

1. auto detection is not working in all cases. I have a diff ready.
2. default behavior for git branch review (the entire branch) is really getting at me.
   e.g. I have this branch checked out and my own commit on top. crit would show me all 1300 lines instead of just what I added. at minimum, it should be possible to select the base revision for the diff. ideally, we will also do something intelligent automatically. I don't mind sending a diff for this one.

I think it will be best if you land this diff first, unless you want to fix the detection problem yourself.

Updated: rc2 binaries available

Rebased on latest main (732e844), all review findings fixed. New binaries:

v0.0.0-sapling-rc2 pre-release

# macOS (Apple Silicon)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc2/crit-darwin-arm64 -o crit && chmod +x crit

# macOS (Intel)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc2/crit-darwin-amd64 -o crit && chmod +x crit

# Linux (x86_64)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc2/crit-linux-amd64 -o crit && chmod +x crit

# Linux (ARM64)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc2/crit-linux-arm64 -o crit && chmod +x crit

Or build from source: go install github.com/tomasz-tomczyk/crit@feat/sapling-scm-support

@omry — would love to hear how it works for you! If auto-detection isn't picking up your Sapling repo, crit --vcs sl should force it.

1. auto detection is not working in all cases. I have a diff ready.

Sure! Happy for you to fork off of this branch? Or you can share the diff and I can have Claude figure it out 😅

default behavior for git branch review (the entire branch) is really getting at me.
e.g. I have this branch checked out and my own commit on top. crit would show me all 1300 lines instead of just whatI added. at minimum, it should be possible to select the base revision for the diff. ideally, we will also do something intelligent automatically. I don't mind sending a diff for this one.

We do have --base-branch... we also have a commit picker but that's only visible on feature branches so not sure how it works for Sapling.

Is this something we should revisit with #300 do you think? GitHub just added stacked PRs so I wanted to see if it's relevant for git implementation too.

1. auto detection is not working in all cases. I have a diff ready.

Sure! Happy for you to fork off of this branch? Or you can share the diff and I can have Claude figure it out 😅

Hehe, sure.
I'll share my diff here once I test on top of your update.

default behavior for git branch review (the entire branch) is really getting at me.
e.g. I have this branch checked out and my own commit on top. crit would show me all 1300 lines instead of just whatI added. at minimum, it should be possible to select the base revision for the diff. ideally, we will also do something intelligent automatically. I don't mind sending a diff for this one.

We do have --base-branch... we also have a commit picker but that's only visible on feature branches so not sure how it works for Sapling.

not quiet sure if this is the thing that bugs me (or that my solution is really the right one):
my understanding is that currently crit is meant to review uncommitted changes.
It seems to assume that a feature branch with multiple stacked commits should all be reviewed.
For example. I tested it on git and it looks the same.
If I create a branch and make a commit, then have some uncommitted changes and I run crit - it will show me the diff from the base of the branch (including both the committed and uncommitted changes). Is this intentional?

Is this something we should revisit with #300 do you think?

I think it's not related to the sapling support. we can discuss it separately.

GitHub just added stacked PRs so I wanted to see if it's relevant for git implementation too.

They did!?
Wow, that timing :)
I signed up to the waiting list.

This is definitely making #300 much more relevant though and we can discuss it there in light of the upcoming GitHub support.

Here is the diff (this is from sl so not exactry a git diff).
Claude should be able to deal with it.
Ask it to import as a commit to your stack and to review.

changeset:   8e73ba3660362c99f616a30e4e38fa416738d403  (@)
parent:      0ef8be177cc6b20db673dab6289450fc257c2ee5
user:        Omry Yadan <omry@yadan.net>
date:        Sat, 18 Apr 2026 21:31:52 +0800

    fix: detect Sapling repos that store metadata under .git/sl

    Recognize .git/sl as Sapling metadata during VCS auto-detection so mixed
    Git/Sapling repositories select the Sapling backend by default.

    Also include the detected VCS in `crit status` output to make backend
    selection easier to debug.

diff --git a/.gitignore b/.gitignore
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,9 @@
 /crit
 /crit.exe
 
 # Review session files (generated at runtime)
 *.comments.json
 *.review.md
diff --git a/main.go b/main.go
--- a/main.go
+++ b/main.go
@@ -2021,8 +2021,10 @@
 		os.Exit(1)
 	}
 
+	vcsName := ""
 	branch := ""
 	if vcs := DetectVCS(""); vcs != nil {
+		vcsName = vcs.Name()
 		branch = vcs.CurrentBranch()
 	}
 
@@ -2050,15 +2052,16 @@
 	}
 
 	if jsonOutput {
-		printStatusJSON(branch, revPath, revExists, matchedSession)
+		printStatusJSON(vcsName, branch, revPath, revExists, matchedSession)
 		return
 	}
 
-	printStatusHuman(branch, revPath, revExists, matchedSession)
+	printStatusHuman(vcsName, branch, revPath, revExists, matchedSession)
 }
 
-func printStatusJSON(branch, revPath string, revExists bool, session *sessionEntry) {
+func printStatusJSON(vcsName, branch, revPath string, revExists bool, session *sessionEntry) {
 	result := map[string]interface{}{
+		"vcs":                vcsName,
 		"branch":             branch,
 		"review_file":        revPath,
 		"review_file_exists": revExists,
@@ -2096,7 +2099,10 @@
 	}
 }
 
-func printStatusHuman(branch, revPath string, revExists bool, session *sessionEntry) {
+func printStatusHuman(vcsName, branch, revPath string, revExists bool, session *sessionEntry) {
+	if vcsName != "" {
+		fmt.Printf("VCS:         %s\n", vcsName)
+	}
 	if branch != "" {
 		fmt.Printf("Branch:      %s\n", branch)
 	}
diff --git a/sapling_test.go b/sapling_test.go
--- a/sapling_test.go
+++ b/sapling_test.go
@@ -1,6 +1,10 @@
 package main
 
-import "testing"
+import (
+	"os"
+	"path/filepath"
+	"testing"
+)
 
 // Compile-time interface compliance check.
 var _ VCS = &SaplingVCS{}
@@ -185,3 +189,31 @@
 		}
 	}
 }
+
+func TestHasSLDirFrom_DetectsDotSL(t *testing.T) {
+	root := t.TempDir()
+	child := filepath.Join(root, "nested", "repo")
+	if err := os.MkdirAll(filepath.Join(root, ".sl"), 0o755); err != nil {
+		t.Fatalf("mkdir .sl: %v", err)
+	}
+	if err := os.MkdirAll(child, 0o755); err != nil {
+		t.Fatalf("mkdir child: %v", err)
+	}
+	if !hasSLDirFrom(child) {
+		t.Fatal("expected hasSLDirFrom to detect .sl metadata")
+	}
+}
+
+func TestHasSLDirFrom_DetectsDotGitSL(t *testing.T) {
+	root := t.TempDir()
+	child := filepath.Join(root, "nested", "repo")
+	if err := os.MkdirAll(filepath.Join(root, ".git", "sl"), 0o755); err != nil {
+		t.Fatalf("mkdir .git/sl: %v", err)
+	}
+	if err := os.MkdirAll(child, 0o755); err != nil {
+		t.Fatalf("mkdir child: %v", err)
+	}
+	if !hasSLDirFrom(child) {
+		t.Fatal("expected hasSLDirFrom to detect .git/sl metadata")
+	}
+}
diff --git a/vcs.go b/vcs.go
--- a/vcs.go
+++ b/vcs.go
@@ -102,7 +102,8 @@
 		return &SaplingVCS{}
 	}
 
-	// Auto-detect: check for .sl/ first since Sapling repos on top of git have both.
+	// Auto-detect: check for Sapling metadata first since Sapling repos on top of
+	// git can have both backends available.
 	if hasSLDir() {
 		return &SaplingVCS{}
 	}
@@ -114,16 +115,24 @@
 	return nil
 }
 
-// hasSLDir checks whether a .sl/ directory exists at or above the current directory.
+// hasSLDir checks whether Sapling metadata exists at or above the current
+// directory. Sapling repos may store metadata either in .sl/ or in .git/sl/.
 func hasSLDir() bool {
 	dir, err := os.Getwd()
 	if err != nil {
 		return false
 	}
+	return hasSLDirFrom(dir)
+}
+
+func hasSLDirFrom(dir string) bool {
 	for {
 		if info, err := os.Stat(filepath.Join(dir, ".sl")); err == nil && info.IsDir() {
 			return true
 		}
+		if info, err := os.Stat(filepath.Join(dir, ".git", "sl")); err == nil && info.IsDir() {
+			return true
+		}
 		parent := filepath.Dir(dir)
 		if parent == dir {
 			break

One thing I noticed:
Running sl in a git repository, even without doing anything - creates a .git/sl directory.
After this diff, crit will start to default to sl for this repo.

Maybe worth some output when detecting a git repo as sl repo (.git/sl exists) to reduce user confusion.

my understanding is that currently crit is meant to review uncommitted changes.
It seems to assume that a feature branch with multiple stacked commits should all be reviewed.
For example. I tested it on git and it looks the same.

If I understand what you're saying right, yes this is intended. In git terms, when on a featue branch, all changes from that branch will be shown. There are toggles in the header to switch back to just unstaged view or you can select specific commit from what has been comitted.

Not 100% sure how this translates to Sapling though and might need some UX adaptation.

If I create a branch and make a commit, then have some uncommitted changes and I run crit - it will show me the diff from the base of the branch (including both the committed and uncommitted changes). Is this intentional?

Yes. Can switch in the header to just show unstaged.

rc3 — improved detection + config support

@omry thanks for the diff! Applied your changes with one modification to the .git/sl behavior:

What changed

Your diff (applied):

• hasSLDirFrom() extraction for testability
• VCS name shown in crit status output (human + JSON)

Modified behavior for .git/sl:

• .sl/ directory → auto-selects Sapling (unchanged, this is a real Sapling repo)
• .git/sl/ directory → stays on git, prints a hint: Sapling detected. Use --vcs sl or set "vcs": "sl" in config

The reason: running sl once in a git repo creates .git/sl/, so auto-selecting Sapling there would surprise git users who just tried it once.

New: "vcs" config field

You can now set your preferred VCS in .crit.config.json (project-level or global):

{
  "vcs": "sl"
}

This is a preference, not a hard requirement — if sl isn't in PATH, it falls back to git with a warning.

Precedence: --vcs flag > config vcs > auto-detect.

Binaries

v0.0.0-sapling-rc3

# macOS (Apple Silicon)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc3/crit-darwin-arm64 -o crit && chmod +x crit

# macOS (Intel)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc3/crit-darwin-amd64 -o crit && chmod +x crit

# Linux (x86_64)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc3/crit-linux-amd64 -o crit && chmod +x crit

# Linux (ARM64)
curl -L https://github.com/tomasz-tomczyk/crit/releases/download/v0.0.0-sapling-rc3/crit-linux-arm64 -o crit && chmod +x crit

If I understand what you're saying right, yes this is intended. In git terms, when on a featue branch, all changes from that branch will be shown. There are toggles in the header to switch back to just unstaged view or you can select specific commit from what has been comitted.

Not 100% sure how this translates to Sapling though and might need some UX adaptation.

ah, it looks like it's always disabled in sapling:
Generally speaking, sapling has no staging area.
So interesting stuff is either uncommitted (sl status will show that) or committed (sl without arguments shows it).

I suggest the following borrowing terminology from sl status:

M = modified
A = added
R = removed
C = clean
! = missing (deleted by a non-sl command, but still tracked)
? = not tracked
I = ignored

Modified should include M, A, R and !. (diff content via sl diff)
Committed should be the files in the active commit (diff content via sl show).
Later when we do stacked diffs, we can also move up and down the stack (sl prev, sl next).

So interesting stuff is either uncommitted (sl status will show that) or committed (sl without arguments shows it).

Right, so if I was to add commit picker to crit on your default branch, I suppose then this could work? Might have to put off SL integration until that is done then

So interesting stuff is either uncommitted (sl status will show that) or committed (sl without arguments shows it).

Right, so if I was to add commit picker to crit on your default branch, I suppose then this could work? Might have to put off SL integration until that is done then

Base commit picker would be nice, but I think the minimum for sl support is to allow me to select modified (aka dirty) files.
this is similar to the functionality you have for git showing unstaged.

secondary: I think the current default is not useful (at least not for me, on sl).
It would be good if I could change the default view type (to Dirty in my case).