Add --from flag to base worktrees on a non-default branch

[migueltorresvalls]

Summary

• tsk add and tsk create -a ... now accept --from <branch> to base the new worktree's branch on origin/<branch> instead of the hardcoded origin/main.
• Default behavior is unchanged, so existing usage is untouched.
• README documents three concrete use cases for --from (see below).

This is the multi-repo equivalent of git checkout -b B while sitting on branch A — useful when a task stacks on top of a feature branch that has not been merged to main yet.

When --from helps

• Stacking on an unreleased feature branch. Your task depends on a colleague's change that is approved but not yet merged to main. Branching off their feature branch keeps your diff focused on your own work instead of dragging in theirs, and avoids the "merge their branch into mine, then rebase later" dance.
• Long-lived integration branches. When several tasks land into a shared develop (or similar) before promotion, base new worktrees there so each task starts from the state the integration branch is actually in.

Test plan

• go vet ./...
• go test ./... (covers the new --from paths in main_test.go)
• Manual: tsk create <ref> <slug> --from develop -a <repo1> <repo2> — worktrees branched off origin/develop (verified via merge-base + file content)
• Manual: tsk add --from main <repo> from inside a task subdir — worktree branched off origin/main (different sha from origin/develop)
• Manual: default (no --from) still bases on origin/main — regression check
• Manual: tsk close without --force refuses worktrees with no upstream (the branch.autoSetupMerge=false invariant survives the change)

🤖 Generated with Claude Code

[cavalle]

Thanks for the PR! Totally agree this use case needs addressing. A few suggestions:

• Instead of --from, I would call the flag --base
• Instead of just the branch name (e.g. --base dev) I would expect the whole remote-tracking branch (e.g. --base origin/dev) to avoid misleading into thinking the new base branch is local.
• On top of that, I think this is the perfect opportunity to avoid hard-coding origin/main as the default base branch. Both origin and main could potentially be called differently. Ideally, tsk should use the name of the first remote configured (let's assume that's the default if there are multiple ones) and the default branch of that remote. (e.g. if the remote is called upstream and the default branch is called master, this should automatically use upstream/master instead of origin/main as the base branch by default)

[Copilot]

Pull request overview

This PR updates tsk add / tsk create -a … to allow choosing the remote-tracking branch that new worktree branches are based on, instead of implicitly basing everything on origin/main. It also adds logic to detect a repo’s default remote HEAD branch when no explicit base is provided.

Changes:

• Add --base <remote>/<branch> to tsk add and tsk create (when using -a) and thread it into worktree creation.
• Implement default-base detection via refs/remotes/<remote>/HEAD with a ls-remote --symref … HEAD fallback.
• Update tsk close to fetch the upstream’s remote-tracking ref before computing “ahead” count, and add tests for parsing/base selection.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
README.md	Documents the new base-branch behavior and the --base flag, plus use-cases and command synopsis.
main.go	Implements --base, default base detection, and upstream refresh logic in close.
main_test.go	Adds tests covering --base, default-base detection, and remote/branch parsing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cavalle]

LGTM This is what I meant. Thank you! I'd polish the README a bit, but not need to block things now, I can do it myself in a future PR (the changes I'd do go beyond the scope of this PR).

One thing though: Copilot is complaining about something I don't fully understand (same thing in all the comments, I believe). Could you please review and either address or dismiss the comments before merging?

[migueltorresvalls]

@cavalle for reference: the documentation had non flagged arguments appear before flagged arguments, which causes the flagged arguments to be omitted.

Example:

tsk add <repo-path> [<repo-path> ...] [-b <branch>]