Files
vibe-kanban/backend/migrations
Louis Knight-Webb 2829686a71 Add base branch (vibe-kanban) (#100)
* Excellent! Everything compiles successfully.

## Summary

I have successfully implemented the base branch feature as requested. Here's what was accomplished:

###  Completed Tasks

1. **Database Migration**: Created `20250708000000_add_base_branch_to_task_attempts.sql` that adds a `base_branch` column with NOT NULL and default value 'main'

2. **Backend Model Updates**: 
   - Added `base_branch: String` field to the `TaskAttempt` struct
   - Updated all SQL queries to include the new column
   - Modified task attempt creation logic to determine and store the resolved base branch (using provided base_branch or current HEAD branch name with fallback to "main")

3. **Improved Branch Status Logic**: 
   - Replaced the complex branch discovery algorithm with simple use of the stored `base_branch`
   - This gives accurate and consistent results since the base branch is now explicitly known

4. **Updated Operations**:
   - **PR Creation**: Now uses stored base branch as fallback when no explicit base branch is provided
   - **Rebase**: Now uses stored base branch as fallback when no new base branch is specified
   - **Merge**: Already used task context, no changes needed

5. **TypeScript Types**: Regenerated to include the new `base_branch: string` field

### 🔧 Key Implementation Details

- **Base Branch Resolution**: When creating a task attempt, the system now:
  1. Uses the explicitly provided `base_branch` if available
  2. Falls back to the current HEAD branch name of the repository
  3. Defaults to "main" if the repository has no commits or other issues

- **Backward Compatibility**: The migration ensures existing records get a sensible default ("main")

- **API Consistency**: All endpoints that previously calculated base branches now use the stored value, providing consistent behavior

### 🎯 Benefits

- **Accuracy**: No more guessing which branch is the "base" - it's explicitly stored when the task attempt is created
- **Performance**: Eliminates the need to traverse git history to find the "closest" branch
- **Consistency**: Operations like merge, rebase, and PR creation now all reference the same base branch
- **User Control**: Users can specify the base branch when creating task attempts
- **Reliability**: Reduces git-related errors from branch discovery algorithms

The implementation maintains full backward compatibility while providing the accuracy and consistency requested in the task description.

* Perfect! Now the PR creation logic follows the correct precedence:

1. **User's explicit choice**: If the user specifies a `base_branch` in the PR creation request, that takes priority
2. **Stored base branch**: Uses the `base_branch` stored in the task attempt as the default
3. **Config/fallback**: Only falls back to the GitHub config default or "main" if the stored base branch is somehow empty/invalid

This ensures that:
-  The PR defaults to the same base branch that was used when creating the task attempt
-  Users can still override this by explicitly specifying a different base branch when creating the PR
-  There's still a sensible fallback chain in case of edge cases

The behavior now matches the requirement: "The saved base branch should be saved by default, but if the user wishes to change it when creating a PR they can."

* Great! The lint passes with only pre-existing warnings (none related to my changes). 

## Summary

I have successfully updated the "Create GitHub Pull Request" dialog to:

###  Changes Made

1. **Replaced text input with dropdown**: The base branch field is now a `Select` component instead of a text `Input`

2. **Default to task attempt's base branch**: The dropdown now defaults to the `selectedAttempt.base_branch` instead of hardcoded "main"

3. **Populated with available branches**: The dropdown shows all local branches from the `branches` prop, with:
   - Current branch marked with "(current)"
   - Common fallback branches ("main", "master") if not in the list
   - Only local branches (filtered out remote branches)

4. **Proper state management**: 
   - Initial state uses the task attempt's base branch
   - Updates when selected attempt changes via `useEffect`
   - Resets to task attempt's base branch when form is cancelled or submitted

5. **User can still override**: Users can select any available branch from the dropdown, providing the flexibility to change the base branch when creating PRs

### 🎯 User Experience

- **Default behavior**: When opening the PR dialog, the base branch dropdown shows the task attempt's stored base branch as selected
- **Override capability**: Users can click the dropdown to select a different base branch if needed
- **Visual clarity**: The dropdown shows "(current)" next to the current working branch and lists all available local branches
- **Fallback safety**: Even if the stored base branch isn't in the list, common branches like "main" and "master" are available as options

The implementation maintains the principle that the stored base branch is the sensible default while giving users full control to override when necessary.

* prettier

* cargo fmt
2025-07-08 15:13:00 +01:00
..
2025-06-19 21:28:36 -04:00
wip
2025-06-20 22:39:06 +01:00