discard changes: hunk selections

[Byron]

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

Follow-up of #7806.

Tasks

• hunk-selections for discard
  • make hunk section specification clear
  • old-new hunk-subtraction
    • all relevant tests
    • Show what happens if hunk selections aren't sorted (it should work, and keep working)
• hunk-header support when discarding in the CLI

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 PRs

• ⚠️ 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.
• hunk-selections for committing
  • Additive-only should trivially work by allowing sub-hunks.
• reset individual lines (but as free selections of sub-hunks)
  • How does this work with context lines? In theory, they will mess everything up so it's probably something to avoid. After all, they will combine multiple hunks into one and the UI really would have to provide hunks without them.
• See what happens if one tries to commit these special cases (i.e. the 'pretend there is no index' changes)
  • implement remaining ignored cases

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]

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

A member of the Team first needs to authorize it.

[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 28, 2025 7:10am

[Byron]

Hi @estib-vega, I noticed you have been dealing with hunk selections lately, so here is an example on how hunk-selections work for discard (but committing will be the same):

gitbutler/crates/but-workspace/tests/workspace/discard/hunk.rs

Lines 368 to 384 in 47b86e1

	hunk_headers: vec![
	// Discard 2,3, keeping 1,4
	hunk_header("-1,14", "+2,2"),
	// Get 6,7 back
	hunk_header("-2,2", "+1,16"),
	// Remove 6-7
	hunk_header("-1,14", "+6,1"),
	// Get 11 back
	hunk_header("-7,1", "+1,16"),
	// Remove 'ten'
	hunk_header("-1,14", "+9,1"),
	// Remove 20,21,22
	hunk_header("-1,14", "+12,3"),
	// Get 17,18 back
	hunk_header("-13,2", "+1,16"),
	],
	};

The idea is that discarding added lines anchors the selection on the old patch header, and vice-versa.
There is no need to concatenate selections, it's fine to pass single-line selections using the line numbers that the UI already knows.

If there are any questions, please let me know :).

[Byron]

@krlvi I think this can be merged and hooked up the UI right away. However, please note the intentional limitation of refusing to discard hunks when the whole file was added or deleted (see "Notes for the Reviewer" for details). It should be no problem to allow it though if this is a requirement.