feat: Option to view diff with entire file as context

[nikclayton]

Problem description

The diff view of a file splits it into the different hunks, with a few lines of context are shown.

Sometimes you need a lot more context.

Preferred solution

An option (which can be set once, not a toggle that I have to click every time I view a diff) to show the entire file (essentially, infinite context), with the diff regions highlighted as they currently are.

Screenshots

I'm coming from https://git-fork.com/, which can do this, see this screenshot.

Notice also how git-fork colours regions in the scrollbar track to show where diffs in the file occur, and the nature of those diffs (green/red).

[Byron]

Thanks so much for sharing, I'd see how this would be incredibly useful.

And with that I mean both to get infinite context (nobody likes to just get 10 lines each time like on GitHub), as well as to show diff colors in the scrollbar. The latter is probably more of a possible second step that seems harder to achieve than the first one, so is probably best out-scoped.

Thinking about how one would most easily implement this, I'd think that the frontend could get access to the amount of desired context lines and provide a huge number to naturally get patches that contain the whole file. This should be quite straightforward to implement for the backend which already has such a parameter. I don't know how easy it is to refresh the view without a visual jump when the new patch comes in.
CC @krlvi and @PavelLaptev for the product and UX aspect of this, and to @estib-vega for the frontend technicalities.

[PavelLaptev]

@nikclayton Thanks for the feedback.

I'm not sure that always showing the full file is a good idea for performance — some files can be really big. Git Fork, for example, has a button to show the full file, but by default it only shows the changed parts:

Screen.Recording.2025-05-26.at.12.14.38.mov

Another feature I’ve seen is increasing/decreasing context. I don’t find it very useful as it is now, but maybe a global setting for context would be better:

When it comes to showing more context, I like how GH Desktop does it. It hides extra lines, and you can click between changed sections to show more if you need to:

---

We can go with the setting to always show the full file, but I’m not sure it’s the best UX. I think it will help only a few users and not most people, especially with large files.

To sum up, here are a few options we could consider:

• A global setting to always show the whole file
• The ability to fold/unfold extra lines
• A button in the file view to show the full file

There might be other options I haven’t thought of yet.

[nikclayton]

I'm not sure that always showing the full file is a good idea for performance — some files can be really big.

That's why you let the user choose, with "A global setting to always show the whole file", in case they're developing on a potato or similar.

But generally, computers these days are fast. I worry that we seem to have forgotten that when deciding what performance to expect.

I took /usr/share/dict/american-english (104,344 lines, ~ 962K), shuffled it (shuf american-english > american-english.shuffle), and loaded that in to diffuse (https://mightycreak.github.io/diffuse/).

Screencast_20250527_112804.webm

That's less than a second to compute the diff and display it, scrolling through it easily.

diffuse is written in Python.

It's just as fast if I use it in git (git config diff.tool diffuse).

Performance is about the same if you do more extreme things to the file -- e.g., group it in to chunks of 20 lines and put the chunks back together in to a new file in random order.

mkdir split
cd split
split -l 20 ../american-english
ls -1 x* | shuf | xargs cat >> american-english.chunk
diffuse ../american-english american-english.chunk

[Byron]

Thanks so much for sharing this and for the reminder that UIs don't have to be slow, even without an implementation in a compiled language.

Now I wonder if the GitButler elements are done in a certain CSS-style that doesn't help performance, or maybe even hinders it. Thus far the only solution was to avoid creating ~100k elements and instead create them lazily at the very least. From there, rendering or layout in particular can take a long time.

[PavelLaptev]

Now I wonder if the GitButler elements are done in a certain CSS-style that doesn't help performance, or maybe even hinders it.

Yes, it is. We need to make our diff component faster. Right now, it's a bit slow because of the CSS and some hidden JavaScript doing extra calculations. It's a good call to fix it.