feat: implement Stack selected commit right half of workspace page

[ndom91]

🧢 Changes

• Add right-half StackDetails view when selecting a commit, including:
  • FileList
  • Commit header metadata
  • Show commit title + description as two separate styled text entities out of the 1 commit.message field
• Add required redux queries and mutations for getting commit changes and updating commit message
• Fix StackTabs dynamic border-radius changes
• Modify UnifiedDiffView to take a whole TreeChange prop in order to more easily show both worktree changes and committed changes via that 1 component

☕️ Reasoning

[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 3:19pm
gitbutler-web	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 21, 2025 3:19pm

[mtsgrd]

I think you can drop this if statement? Iterating of a zero length array is a no-op.

[ndom91]

Hmm yeah logically you're probably right. I had it here in order to be able ot render at least something (in this case the string "No Content"), when there are no hunks.

Ideally I'd like to just not allow the user to toggle them open when there are no hunks, however, due to the way we have it architected now, we don't know the contents of the file change, i.e. the diff, until when the user opens it.

So its not straight forward to disable toggling open of a file which doesn't have a hunk (i.e. new empty file Addition) without checking them all beforehand, which is what we wanted to avoid, right. You have any good ideas? 🤔

[mtsgrd]

Good point.

@krlvi I think in v2 code we generate a synthetic hunk when there is no diff. It's easier for the front end if we keep that behaviour, but what do you think?

[krlvi]

Surely we could add a synthetic hunk, but on face value this feels like masking another problem. It's totally valid to have no hunks in the file (eg. file executable bit added/removed) - and the app could/should show that.
At the moment I feel like I'd rather favor correctness (of the API) over supporting the existing semantic.

Is there something that I might be missing here?

[krlvi]

And I guess the same applies for commits with no files in them - the app allows their creation, and it should be still possible to preview / edit the message

[ndom91]

@krlvi Yeah +1

I was just reading through the types again and it seems like we could disable the opening of these types of file with those flags too. Would it be a lot of work on your end to add a EmptyFile TreeChange.status Flag?

[mtsgrd]

@ndom91 my intuition is that we should still allow the file to be opened, but show a message where we otherwise have a diff.

[ndom91]

Okay yeah I'm open to whatever. Maybe Pavel has a nice design idea haha

[mtsgrd]

Not yet, but we will at some point. For now we can just drop some text in its place?

[ndom91]

Right. Currently there is some text there and it just says "No Content" i.e.:

[ndom91]

@mtsgrd you wanted to potentially get rid of this file btw, is that still the case?

I had to fix one or two TS-related things here in this file in order to get the project to build and then just kept going a bit further haha

[mtsgrd]

Yeah we can drop SelectionView.svelte!

[ndom91]

Sounds good. Dropped!