discard changes: hunks

[Byron]

Add V3 facilities for discarding changes in the worktree or index, this time it's about hunks specifically.

Follow-up of #7597.

Tasks

• figure out what's going on with the test and 'object not found' (and fix it)
• fix content-conversions and hunk-references into said content for commit-engine
• fix tree/index/worktree bug
  • assure tests for no-ops
  • check with symlinks at least once
  • deduplicate match - no need, will just be harder to read then

For next PR

• reset changed hunks in a file
• merge various improvements GitoxideLabs/gitoxide#1898 and refer to it from main.

Notes for the reviewer

• I find it difficult to imagine how meaningful discarding parts of hunks in whole-file deletions and additions can be so I chose to disallow it. The UI can still offer discarding the single whole hunk that a deletion or addition of a file would come with, but internally it, as always, would discard the file instead. Discarding of lines or selections would have to be disallowed on the UI level though, as this is currently only available for modified (or renamed + modified) files.

For the next PR

• See what happens if one tries to commit these special cases (i.e. the 'pretend there is no index' changes)
  • implement remaining ignored cases
• gitoxide informs about diff-filter changes and this information is passed to the frontend
  • differentiate binary-to-text , otherwise it applies worktree conversions (which is fine). We ignore external diff programs anyway.
• reset individual lines (but as free selections of sub-hunks)

Shortcomings

• Index-handling is low-level and I think there needs to be something like a tree-editor, but for indices. Maybe it's a mix of using the pretty-neat tree-editor, and a way to transfer index information from one index to another, similar to 'apply', to avoid loosing information.

Out of Scope

• snapshot integration - should be left to @krlvi to warm up with the new code.

Research

• V2 implementation
  • spread across unapply_lines, unapply_ownership and reset_files

[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	Mar 21, 2025 8:23am

[vercel]

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

A member of the Team first needs to authorize it.

[Byron]

@Caleb-T-Owens The issue mentioned in Discord is now fixed, and led to the realisation that an entire bag of problems with worktree changes was nearly entirely ignored previously. Now I see that what GitButler really is doing is to "pretend the index doesn't exist". For the typical user and GitButler-exclusive operation that is the case even, and the index is always matching the tree it was created from.
When users start to bypass GitButler, it's possible that git add is invoked which adds new complexity. Previously GitButler would just ignore these tree/index changes, but also erroneously show diffs only between the index and the worktree.
Now both views are merged in a match statement with 16 cases, with only 6 that I don't think can actually happen. 4 of these possible cases are a bit unclear to me still and I left them for another day.
It's notable that this merge essentially synthesises an index/worktree change.

Every handled case (even those that aren't implemented yet) has a specific test-case to trigger it, which makes deciding what should be done very easy.

Follow-up PRs have to deal with the todo!() cases, but additionally I am interested in seeing what the commit-engine does when these synthetic changes are passed in. The question is really around index handling, and I would assume that it won't work correctly. Yet my hope is that it 'somewhat' works and that it resolves itself without being (too) incorrect. After all, these cases can be considered rare for now, even though they are a possibility.

Thinking about it, now that this is implemented, the UI could be used for testing how certain edge-cases will work quite easily, the test-cases show how these states can be triggered.

And yes, I guess you can take this as invitation to break it :D.

@krlvi I am merging this without review as this is only refactors in preparation for chunk-handling, along with plenty of fixes.

[Caleb-T-Owens]

Thanks @Byron.

I'm starting to use the v3 client where possible, so I can hopefully exercise most of these