id: 002 title: Handle remote branch conflicts in init command status: completed type: enhancement priority: high tags: [init, remote, git] assignee: created: 2025-09-27T10:00:00Z updated: 2025-09-27T18:00:00Z completed: 2025-09-27T16:00:00Z

Handle remote branch conflicts in init command

Problem Description

The current tissue init command has several issues with remote branch handling that can lead to conflicts and unexpected behavior in distributed Git environments:

1. Hardcoded remote assumption: The command assumes “origin” remote exists and pushes to it without verification (cmd/init.go:216)
2. No remote branch detection: Doesn’t check if the issues branch already exists on any remote
3. Multiple remotes not handled: When multiple remotes exist with the same branch name, there’s no way to specify which one to use
4. Silent push failures: Push failures are only logged as warnings, potentially leaving users unaware of sync issues

Edge Cases to Consider

Case 1: No remotes configured

• Current: Skips push (correct behavior)
• Expected: Continue as-is ✓

Case 2: Single remote (not named “origin”)

• Current: Push fails silently
• Expected: Should detect and use the single remote

Case 3: Multiple remotes, none with issues branch

• Current: Pushes to “origin” if it exists
• Expected:
  • if –remote flag set
    • should check if that remote exists, and then push to it
  • if –remote flag not set
    • Should not push to any remote
    • print output saying that no pushing has occured
    • print how to tissue init with a remote (–remote flag)
    • print how the user can set and push the issues branch/worktree with normal git commands

Case 4: Multiple remotes, one has issues branch

• Current: May create conflicting local branch
• Expected: Should detect and:
  • Log that the dectected matching remote branch was found
  • Checkout and track the existing remote branch

Case 5: Multiple remotes, multiple have issues branch

• Current: Creates local branch, pushes to “origin”
• Expected: Should require explicit remote selection (–remote flag)

Proposed Solution

1. Add --remote flag to specify which remote to use
2. Add --force-local flag to bypass remote checks
3. Implement remote branch detection to avoid conflicts
4. Smart remote selection:
   • Single remote: use it automatically
   • Multiple remotes: require –remote flag or skip push
   • Detect and track existing remote branches
5. Better error handling for SSH and connectivity issues

Test Cases Summary

1. No remotes: Creates local branch, sets up worktree ✅
2. Single remote (not “origin”): Auto-detects and uses it ✅
3. Multiple remotes, no issues branch: Requires –remote flag or skips push ✅
4. Multiple remotes, one has issues: Tracks existing branch ✅
5. Multiple remotes, multiple have issues: Requires –remote flag ✅
6. Unreachable remote: Shows warning, continues locally ✅
7. Invalid –remote flag: Fails with clear error ✅
8. Local issues branch exists: Fails with appropriate message ✅
9. Local branch exists, worktree missing: Reuses branch ✅ Fixed
10. SSH connectivity issues: Uses –force-local flag ✅ Fixed

Implementation Updates

Code Cleanup (2025-09-27)

• Removed redundant and obvious comments throughout the code
• Added git command equivalents as comments for clarity (e.g., git rm -rf ., git add, git push)
• Simplified the contains() function to use strings.Contains()
• Fixed syntax error (missing closing brace in file removal loop)
• Improved error handling consistency
• Removed empty else blocks and unnecessary control flow
• Made logging more deliberate and git-like (minimal output)
• Success message now shows only: “Initialized tissue in issues/”

SSH Handling Simplification

• Removed complex SSH config parsing that was “way out of control”
• Let go-git handle SSH authentication natively
• Added --force-local flag to bypass remote checks when needed
• Fail silently on SSH errors rather than blocking initialization