apply-branch

[Byron]

Make workspace updates possible, i.e. rebasing multiple branches in a workspace onto a new base.

Follow-up on #7315.
Sibling of #7330

Tasks

• research
• metadata API sketch
• test-cases
• capture worktree changes
• deal with merge failures
• TODO: fix ref-rewrite issue to assure only the latest ref is rewritten

Known Shortcomings (for now)

• empty commits aren't specifically highlighted when rebasing, or handled or prevented. The UI could detect that and show them.
• Moving hunks or files will need multi-branch rebases with merge-commit handling. This can be added to the rebase engine as we know it today. This will also enable worktree-updates.
• reordering in such a way that only heads a moved and nothing else happens (in terms of commit rewrites) probably wouldn't work yet in but-rebase.
• Index adjustments (tree to disk index) lack a lot of tests, particularly those for automatic conflict removal.
• if changes are added to the wrong spot, then they may apply cleanly and yield different results after merging, so the worktree differs from what's in Git. This is where hunk-dependencies/auto-hunk-splitting comes into play.
• Right now sub-hunks can't be selected as they won't match when it tries to find exact matches. However, that check could be changed to a 'contains' or 'is-included' to allow sub-hunks. Maybe this doesn't naturally work though or do the right thing.
• Workspace commits with a single branch will get signed if they were signed before. This shouldn't be a real problem, and ideally it will go away soon enough.
• ⚠️ merge conflicts are created from either cherry-picks or normal merges (legacy?), but cherry-pick would need to know that to either choose the auto-resolution. That's OK as long as the 'old' merge-commit isn't run as it would create a semantically different tree-setup in the conflicted commit.

For follow-up PRs

In any order (probably)

• Apply Branch/Unapply Branch
  • Don't rebase newly applied branch, just merge it in.
  • Rebasing only when explicit update is required - avoid rebasing
• Rebase-engine with insert empty commit (below and above, insert as first parent support)
• What happens in Git if one rebases non-linear branches? Can it retain the structure?
  • Rebase engine probably has to learn to re-schedule picks (and remember the base, a feature useful for multi-stacks as well, which then wouldn't need a special case anymore)
• move file out of commit into worktree (uncommit something)
• per-hunk exclusion if hunk didn't match (right now it rejects the whole file)
• run hooks on an index created from the tree that would be committed.
• move hunks from one commit into another

Out of scope

• hunk-dependencies
  • These should be added once the commit-engine is feature-complete, the idea is that the UI can function well enough without them as a baseline.
• atomic object writes
  • In theory, new objects should only be written to disk if they actually end up in a tree. For instance, if a change is rejected, the object associated with it shouldn't be in the object database.
  • However, even though implementing this with the in-memory object feature is very possible, it feels like an optimization for another day. In general, I really think only objects that end up in a tree should actually be written, so that the implementation doesn't have to rely on git gc to cleanup.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
gitbutler-components	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 21, 2025 6:09pm

[vercel]

@Byron is attempting to deploy a commit to the GitButler Team on Vercel.

A member of the Team first needs to authorize it.