feat(tasks): add configurable base branch for worktree creation and m…

[qaziatiq]

I wanted the ability to create worktrees from my develop branch, instead of the main branch, added this on starting the task so the merge goes back to the branch of your choice (from where you had checked it out) instead of main branch.

• Add optional baseBranch parameter to createTask and mergeTask flows
• Add base branch input field in NewTaskDialog with auto-detection
• Pass baseBranch as startPoint to git worktree add command
• Use baseBranch as merge target instead of auto-detected main branch
• Persist baseBranch in Task and PersistedTask types
• Add validation for baseBranch parameter in IPC handlers

[johannesjo]

Thank you very much for this and sorry for the late reply. Somehow I wasn't receiving notifications for PRs opened here....

Code Review

Nice feature – the ability to branch from and merge back to a non-main branch is a solid addition. The implementation is clean, minimal (+107/-5), backward compatible, and follows existing codebase patterns well.

Strengths

• Well-scoped change threading baseBranch through UI → store → IPC → git operations
• All new params are optional with ?? fallbacks — existing tasks work unchanged
• Good SolidJS reactivity: createEffect with cancelled flag + onCleanup matches existing patterns
• baseBranch correctly persisted in both active and collapsed task paths

---

Issues to address

1. Missing branch name validation (security)

baseBranch and targetBranch are validated with assertOptionalString() only, but are passed directly to git commands (git worktree add, git checkout). A value starting with -- could be interpreted as a git flag by git itself (even though execFile prevents shell injection).

The codebase already has validateBranchName() in register.ts which rejects strings starting with -. Please add it for both parameters:

// in CreateTask handler
if (args.baseBranch) validateBranchName(args.baseBranch, 'baseBranch');

// in MergeTask handler  
if (args.targetBranch) validateBranchName(args.targetBranch, 'targetBranch');

2. Inconsistent base branch across related operations (design)

mergeTask correctly uses the custom base branch, but several related functions still auto-detect main via detectMainBranch():

• checkMergeStatus() — merge dialog shows status against auto-detected main while the actual merge goes to the custom branch. Could show wrong "Nothing to merge" state.
• rebaseTask() — rebases against auto-detected main, not the configured base branch
• getBranchLog() — commit history shown relative to wrong branch
• getWorktreeStatus() — uses detectMainBranch to determine committed changes count
• getAllFileDiffsFromBranch, getChangedFilesFromBranch, detectMergeBase — may affect diff views

A user working against develop would see merge status/diffs compared to main, which is misleading.

This doesn't need to block the PR if you plan a follow-up, but at minimum checkMergeStatus should use the custom base branch since it directly feeds the merge dialog.

---

Minor

3. No pre-validation that baseBranch exists as a ref. A typo like develp fails with a raw git error. A git rev-parse --verify pre-check would give a friendlier message. Nice-to-have.

---

Verdict

Good work overall. Please fix #1 (security), and let's discuss the approach for #2 — either address in this PR or plan follow-up.

[qaziatiq]

Good catch had not thought about it, let me work on it will update :)

[johannesjo]

Thank you @qaziatiq !