Documentation

Authentication for Push/Pull Operations

Critiq will use connected provider tokens (GitHub/GitLab) for HTTPS remotes when available; otherwise it falls back to your system git configuration (SSH or your credential helper). Configure one of the flows below to keep push/pull/fetch seamless.

In-App OAuth (GitHub/GitLab)

Critiq supports OAuth sign-in for GitHub, GitLab BitBucket and Azure DevOps so you can connect accounts without manually managing tokens. Use this for PR review, branch browsing, and cloud-aware workflows—plus HTTPS push/pull/fetch when a linked account matches the remote.

1. Open Critiq and go to Settings → Accounts.
2. Click “Sign in with {provider} and complete the OAuth flow.
3. For HTTPS remotes, Critiq will use your connected account token for push/pull/fetch; SSH remotes still use your keys.

Self-Hosted Git Providers (Gitea/Forgejo/GitLab)

Critiq supports self-hosted Git providers like Gitea, Forgejo, and GitLab Self-Hosted with full OAuth authentication. You can configure multiple instances with custom names and credentials.

Gitea / Forgejo Setup

1. Create OAuth Application in Gitea/Forgejo:
   • Navigate to your Gitea/Forgejo instance (e.g., https://git.company.com)
   • Go to Settings → Applications → OAuth2 Applications
   • Click Create a new OAuth2 Application
   • Fill in:
     • Application Name: Critiq
     • Redirect URI: http://localhost:8765/callback
     • Permissions: Select repo and user:email
   • Save and copy the Client ID and Client Secret
2. Add to Critiq:
   • Open Critiq and go to Settings → Integrations → Self-Hosted Providers
   • Click Add Self-Hosted
   • Fill in:
     • Name: A friendly name (e.g., "Work Gitea")
     • Platform: Gitea / Forgejo
     • Base URL: Your instance URL (e.g., https://git.company.com)
     • OAuth Client ID: Paste from step 1
     • OAuth Client Secret: Paste from step 1
     • OAuth Scopes: repo, user:email (or leave empty for defaults)
   • Click Add Provider
   • Click Connect with OAuth to authenticate

GitLab Self-Hosted Setup

1. Create OAuth Application in GitLab:
   • Navigate to your GitLab instance
   • Go to User Settings → Applications
   • Fill in:
     • Name: Critiq
     • Redirect URI: http://localhost:8765/callback
     • Scopes: api, read_repository, write_repository
   • Save and copy Application ID and Secret
2. Add to Critiq:
   • Open Critiq and go to Settings → Integrations → Self-Hosted Providers
   • Click Add Self-Hosted
   • Fill in:
     • Name: A friendly name (e.g., "Company GitLab")
     • Platform: GitLab Self-Hosted
     • Base URL: Your instance URL (e.g., https://gitlab.company.com)
     • OAuth Client ID: Paste Application ID from step 1
     • OAuth Client Secret: Paste Secret from step 1
     • OAuth Scopes: api, read_repository, write_repository (or leave empty for defaults)
   • Click Add Provider
   • Click Connect with OAuth to authenticate

Note: Self-hosted providers work exactly like built-in providers—OAuth tokens are used for HTTPS push/pull/fetch, code review features are fully supported, and repositories are automatically matched by remote URL hostname.

Recommended: SSH Keys (Most Common)

SSH keys are the most reliable and secure method for git authentication.

Setting up SSH Keys

1. Generate an SSH key (if you don't have one):

   ssh-keygen -t ed25519 -C "your_email@example.com"

   Press Enter to accept the default file location and optionally set a passphrase.
2. Add your SSH key to the ssh-agent:

   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_ed25519

3. Add the public key to your git provider:
   • GitHub: Copy your public key: cat ~/.ssh/id_ed25519.pub → Go to GitHub Settings → SSH and GPG keys → New SSH key → Paste your public key and save
   • GitLab: Copy your public key: cat ~/.ssh/id_ed25519.pub → Go to GitLab Preferences → SSH Keys → Paste your public key and save
   • Azure DevOps: Copy your public key: cat ~/.ssh/id_ed25519.pub → Go to User Settings → SSH public keys → Add → Paste your public key and save
4. Update your git remote to use SSH (if currently using HTTPS):

   cd /path/to/your/repo
   git remote set-url origin git@github.com:username/repository.git

Alternative: GitHub CLI

If you primarily use GitHub, the GitHub CLI provides an easy authentication setup:

1. Install GitHub CLI: https://cli.github.com/
2. Authenticate:

   gh auth login

   Follow the prompts and select "HTTPS" when asked about git protocol.

This configures git credential helper automatically.

Alternative: Git Credential Manager

For HTTPS authentication with credential storage:

1. Install Git Credential Manager (comes with Git for Windows, separate install on macOS/Linux)
2. Configure git to use it:

   git config --global credential.helper manager-core

3. First push/pull will prompt for credentials and store them securely

Troubleshooting

"Permission denied (publickey)" error

• Your SSH key is not added to your git provider
• Follow the SSH setup steps above

"Authentication failed" error

• If using HTTPS, configure Git Credential Manager or GitHub CLI
• Or switch to SSH authentication (recommended)

Previous OAuth-based git clients

If you previously used a git client with its own OAuth authentication system, that authentication won't work with standard git tools. You'll need to set up SSH keys or use one of the alternative methods above.

Commit Signing

Git supports cryptographically signing commits to verify authorship. You can use either GPG keys or SSH keys for signing.

Option 1: Sign commits with SSH keys (Git 2.34+)

Use your existing SSH key for both authentication and signing:

1. Configure git to use SSH for signing:

   git config --global gpg.format ssh
   git config --global user.signingkey ~/.ssh/id_ed25519.pub

2. Enable automatic commit signing:

   git config --global commit.gpgsign true

3. Add your signing key to your git provider:
   • Settings → SSH and GPG keys → New SSH key → Select "Signing Key" as key type

Option 2: Sign commits with GPG keys

Traditional GPG signing (supported by all providers):

1. Generate a GPG key:

   gpg --full-generate-key

   Choose RSA and RSA, 4096 bits, and enter your name and email.
2. List your GPG keys and copy the key ID:

   gpg --list-secret-keys --keyid-format=long

   Copy the key ID (the part after rsa4096/)
3. Configure git to use your GPG key:

   git config --global user.signingkey YOUR_KEY_ID
   git config --global commit.gpgsign true

4. Export and add your public key to your git provider:

   gpg --armor --export YOUR_KEY_ID

   Copy the output and add it to the provider:
   • GitHub: Settings → SSH and GPG keys → New GPG key
   • GitLab: Preferences → GPG Keys
   • Azure DevOps: User Settings → GPG Keys

Verification

Once configured, all commits made through Critiq (and git CLI) will be automatically signed. Your git provider will show a "Verified" badge on signed commits.

Additional Features

Branch Context Menu

Right-click any local branch in the branch dropdown to:

• Push - Push commits to remote (shows if branch is ahead)
• Pull - Pull commits from remote with fast-forward only (shows if branch is behind)
• Fetch - Fetch latest changes from remote without merging

File Context Menu

Right-click any file in the changes pane to:

• Stage/Unstage - Move files between staged and unstaged
• Discard Changes - Discard staged or unstaged changes (context-aware)
• Delete File - Delete untracked or newly added files

Keyboard Shortcuts

• Ctrl/Cmd + P - Toggle quick file search
• Ctrl/Cmd + H - Previous file (navigate file history in working changes)
• Ctrl/Cmd + L - Next file (navigate file history in working changes)
• Ctrl/Cmd + J - Next hunk
• Ctrl/Cmd + K - Previous hunk
• Ctrl/Cmd + Shift + J - Next file in changes list
• Ctrl/Cmd + Shift + K - Previous file in changes list
• Ctrl/Cmd + S - Stage/unstage current hunk (or save file in edit mode)
• Ctrl/Cmd + Shift + S - Stage/unstage entire file
• Ctrl/Cmd + E - Toggle edit mode
• Ctrl/Cmd + Shift + R - Toggle file reviewed status (PR mode)

Note: All keyboard shortcuts can be customized in Settings.

Language Server Protocol (LSP) Support

Critiq provides intelligent code features like hover information, go-to-definition, and symbol search through Language Server Protocol (LSP) integration. LSP servers are automatically detected and started based on the languages in your repository.

Supported Languages (Default Configuration)

Out of the box, Critiq supports the following languages:

• Go - gopls
• Rust - rust-analyzer
• C# - OmniSharp
• Vue - vue-language-server (Volar)
• TypeScript/JavaScript - typescript-language-server (provides full project context)
• Python - pylsp (disabled by default, enable in config if installed)

Installing Language Servers

Language servers must be installed separately on your system. Critiq will automatically find them if they're in your PATH or in common installation locations.

Go (gopls)

go install golang.org/x/tools/gopls@latest

Rust (rust-analyzer)

rustup component add rust-analyzer

C# (OmniSharp)

Download from: https://github.com/OmniSharp/omnisharp-roslyn/releases

Vue (Volar)

npm install -g @vue/language-server

TypeScript/JavaScript

npm install -g typescript-language-server typescript

Python (pylsp)

pip install python-lsp-server

Customizing LSP Configuration

You can customize language server behavior by creating a configuration file at:

• Linux/macOS: ~/.config/critiq/lsp-servers.json
• Windows: %APPDATA%\critiq\lsp-servers.json

Configuration Examples

Enable Python LSP:

{
  "python": {
    "enabled": true
  }
}

Disable a language server:

{
  "csharp": {
    "enabled": false
  }
}

Custom installation path:

{
  "go": {
    "command": "gopls",
    "searchPaths": [
      "/custom/path/to/gopls",
      "/home/user/go/bin/gopls"
    ]
  }
}

Add custom arguments and initialization options:

{
  "go": {
    "command": "gopls",
    "args": ["-logfile", "/tmp/gopls.log"],
    "initializationOptions": {
      "usePlaceholders": true,
      "completionDocumentation": true
    }
  }
}

Add a new language server:

{
  "ruby": {
    "enabled": true,
    "command": "solargraph",
    "args": ["stdio"],
    "fileExtensions": ["rb"]
  }
}

Configuration Options

Each language server can be configured with the following options:

• enabled (boolean) - Whether to enable this language server. Default: true
• command (string) - The executable command name or path
• args (array) - Command line arguments to pass to the language server
• fileExtensions (array) - File extensions this server should handle (e.g., ["go"])
• searchPaths (array) - Custom paths to search for the executable if not in PATH
• initializationOptions (object) - LSP-specific initialization options passed to the server

Your custom configuration will be merged with Critiq's defaults, so you only need to specify the options you want to change.

Troubleshooting LSP

Language server not starting:

1. Check that the language server is installed: which gopls (or relevant command)
2. Check the console logs in Critiq for error messages
3. Verify the language server works from command line
4. Add a custom searchPaths in your config if installed in a non-standard location

No code intelligence features:

1. Ensure files are saved (LSP servers work on saved file content)
2. Wait a few seconds for the language server to initialize on first use
3. Check that the file extension matches the configured fileExtensions

Language server performance issues:

1. Large repositories may take time to index
2. Check language server documentation for performance tuning options
3. Add tuning options via initializationOptions in your config