Help test the new stage-hunks-in-main-view feature

[stefanhaller]

In case you missed it, I have been working on a major change to lazygit which gets rid of the staging and custom-patch-building panels, and allows staging hunks directly from the main view instead. See #5732 for more, which is a prototype of that.

I have started to reimplement the prototype for real, and am far enough that I think it's worth testing it already. There's no PR yet (it's actually going to be a stack of at least 8 PRs, maybe more), but I have an integration branch where everything is squashed and allows testing it. I have been using that branch in my daily work for quite a while now, so you can trust me that it's reasonably stable.

You can install this build using

go install github.com/jesseduffield/lazygit@sh-integration

If you are using any of the diff renderers delta, difftastic, or diff-so-fancy, you need special builds of these as well to make the whole thing fun. You can install them as follows:

• delta:

  cargo install --git ssh://git@github.com/stefanhaller/delta.git --branch osc-1717-metadata
  

• difftastic:

  cargo install --git ssh://git@github.com/stefanhaller/difftastic.git --branch osc-1717-metadata
  

• diff-so-fancy: download it from here and put it somewhere in your PATH.

Make sure that ~/go/bin and ~/.cargo/bin are in your PATH.

I'm very interested in feedback; both about things that simply don't work right yet, and about things where the UX has changed for the worse in your opinion. Since we don't have a PR yet, I'm opening this issue as a place to give feedback.

A few features that may not be obvious to find:

• select a line or hunk in the main view, and press e to jump to your editor on that line
• even easier: hold option or shift (depending on your terminal) and click a line to edit it (this works even if it is behind a popup, e.g. the commit message editor)
• with the main view focused, press f to bring up a menu with all the files in the diff, to quickly jump to one (this menu can be filtered simply by typing, no need to press /)

[sgtrusty]

Hi @stefanhaller , just tested this in a Linux-based sandbox. Sorry for the delays! Been a bit busy with projects of my own and professional pursuits 👔

It works pretty well. I couldn't get the f to show any files beside the currently opened one in the main view.

I also couldn't get the hold option or (...) and click a line to edit it to work -- i'm using Ghostty + bash on Arch Linux 7.0.12-arch1-1. Correction: shift doesnt work, there is no opt in my keyboard. But <Alt> does work.

Note

Good job!

Is it necessary to create a tester plan for this, maybe with a list of the intended functionalities and manual test case paths? If so maybe I can help you out to draft one quickly. Great job with the changes, I look forward to having this in my main workflows :)

[stefanhaller]

I couldn't get the f to show any files beside the currently opened one in the main view.

That's the case when a single file is selected in the side panel, or a commit that only changes one file. It is indeed questionable if the f menu should appear at all in that case, it's a bit pointless there. It is useful when viewing a commit that changes many files, or when selecting a directory in the Files panel (I like to keep the / root of the working tree selected most of the time to see the full diff of all my changes).

Is it necessary to create a tester plan for this, maybe with a list of the intended functionalities and manual test case paths?

I feel that's a bit too early; this will be easier when the actual PRs are available, the PR descriptions (and maybe the commit messages) can probably help a lot with that.

For now I'm mainly interested in any limitations that you run into during daily work; things that worked well for your particular workflow and no longer do. Testing it in your daily work would be most useful; artificial testing in a sandbox not so much.

I'm also very interested in how well staging works when difftastic is the main diff viewer; I only use it very occasionally.

[ChrisMcD1]

Howdy,

I have found a bug when incrementally staging files with spaces a directory name. My lazygit debugging skills have gotten poorer, and I don't see anything in the debug logs, so I can't really point to what caused it, but here's my reproduction:

Reproduction:

mkdir reproduction
cd reproduction
git init
mkdir "Directory With Space"
seq 10 > foo.txt
lazygit
> Press Enter to go into "Unstaged changes" panel
> Press Space to stage, either in line mode or hunk mode
> See "Apply patch" in the logs with no additional git command information.
> See that no part of the file has been staged

I want back to normal lazygit and tested on the same test repro and the staging worked, so I'm reasonably confident that the setup repository is not corrupted in some way (Which is what I was thinking when I first encountered this on my main work repository)

[stefanhaller]

@ChrisMcD1 There must be information missing in your repro. Did you mean to cd into "Directory With Space" after the mkdir? And when pressing enter, what was selected? If the dir is selected, it just folds it, so I assume it was foo.txt.

I tried to reproduce it with those assumptions, but it's working fine for me, so there must be something else.

[ChrisMcD1]

True, the file needs to be inside of Directory With Space. Here is the updated reproduction. Running on MacOS 27.0 with git 2.51.0.

mkdir reproduction
cd reproduction
git init
mkdir "Directory With Space"
seq 10 > "Directory With Space/foo.txt"
lazygit
> Press 2 so you are on the "Files" section. (Shouldn't be necessary)
> Press Down so you are selecting "foo.txt" nested under "Directory With Space"
> Press Enter to go into "Unstaged changes" panel
> Press Space to attempt stage the first line of the file into a patch.
> See "Apply patch" in the logs with no additional git command information.
> See that the main screen does not respond to your press of Space. Normally it would split vertically to have both an "Unstaged Changes" and "Staged Changes"

[ChrisMcD1]

Okay, I've identified part of the problem. Failing unit test is available at https://github.com/ChrisMcD1/lazygit/tree/test-trailing-spaces

Walking it back from the crash:

• Lazygit fails to find the current file in the list of files
• This is because the current file's path ends as foo.txt (with 2 spaces) instead of foo.txt, which is how the list of files knows the path
• This is because the parser that the failing unit test is on interprets the git diff output (which does have 2 spaces at the end of the file path) as meaning the files' actual name ends with 2 spaces, which it does not!

I don't know if it is a problem in the git diff output to have 2 spaces in the lines +++ b/Directory With Space/foo.txt , or a problem with lazygit's parsing of those spaces.
Uncommenting the basic strings.TrimWhitespace in my branch got me past the point of crashing and I was able to stage lines once again. Certainly not a complete fix though. The highlighting still looked quite broken after that change, as seen below.

My branch's highlighting

Master branch highlighting

[stefanhaller]

@ChrisMcD1 Thanks, fixed; please pull the new version of sh-integration.

What was going on here: in the --- a/Directory With Space/foo.txt line, git appends a \t whenever the path contains spaces; it's invisible above. This tab is actually significant and is needed for parsing the diff header correctly. What was happening is that gocui renders the diff content into the view, at which time the tab gets expanded to spaces; then, lazygit takes the view's cell content and parses it again as a diff, which fails because the tab got lost.

To fix this, a gocui view now retains the original input alongside the rendered cells, and the diff parser can use that to faithfully reconstruct the original diff. See b0a1882.

As for "highlighting still looked quite broken": this is intentional, see ee59554. It looks a little weird when a single line is selected, but it makes more sense when a whole change block is selected, and especially with a diff renderer like delta.

[scottchiefbaker]

I'm late to the game, but so I'm just getting around to testing this. In this testing version of Lazygit with diff-so-fancy here is my workflow:

1. In the files panel I hit enter to get into hunk mode for that file
2. It defaults to "select hunks" but allows me to toggle to line-by-line
3. I use the arrow keys to navigate to each hunk
4. Press spacebar to add that hunk to the staged changes

Initial tests show things are working correctly when piped through d-s-f. I have a couple of implementation questions:

1. Is there a keyboard shortcut to shift to the "Staged changes" box if I want to remove a hunk? The other boxes all have number shortcuts but that one doesn't? It would be nice if this were 6 to make jumping from the left side to the right easier.
2. The UI for adding a hunk highlights (only?) the first two characters of the line in blue. Is this by design? Lazygit does not highlight the entire line/hunk?

[stefanhaller]

Is there a keyboard shortcut to shift to the "Staged changes" box if I want to remove a hunk?

<tab>, if you are in the "Unstaged changes" panel. There is no direct way to go to "Staged" when the focus is in the side panel; you'll have to press 0 <tab> for that. I don't want to assign 6 to it because that's useful when you configure more than 5 side panels; for example, I have worktrees in a side panel of its own, so Stash is [6] for me.

The UI for adding a hunk highlights (only?) the first two characters of the line in blue. Is this by design?

Yes, this was mentioned in the comment right above yours. See ee59554's commit message for an explanation.

Since this seems to look wrong to people: if you have any better idea how to solve the problem, I'm all ears. I already experimented with various different approaches, and settled on this one as the least ugly one. Painting the whole line's background blue is not an option.

[scottchiefbaker]

What if, when you're in hunk selection mode it adds a space (maybe two?) of padding on the left side, and your blue selection is drawn in that newly added whitespace? Maybe put some >> in the selection to give a visual indicator that it's pointing at something instead of just highlighting empty space?

Right now the two chars makes me think it's only going to add that part of the line (not the whole thing).

[acampove]

The version you posted seems to be buggy, when I stage one file and then commit, it commits all the changes, even the non staged ones and even in different files.

Edit: This seems to also be happening in the master branch, 5fcbdad

[stefanhaller]

What if, when you're in hunk selection mode it adds a space (maybe two?) of padding on the left side, and your blue selection is drawn in that newly added whitespace? Maybe put some >> in the selection to give a visual indicator that it's pointing at something instead of just highlighting empty space?

This might work for staging, but it doesn't work so well for patch building (when a commit is selected), in which case we already add an extra column on the left for showing the checkmarks for inclusion of a hunk in the custom patch. Also, I feel the >> idea would only look ok for a single selected line, but not for a block of changes, which is the more common case.

[stefanhaller]

The version you posted seems to be buggy, when I stage one file and then commit, it commits all the changes, even the non staged ones and even in different files.

@acampove This must be some sort of misunderstanding or usage error, and I'm interested in finding out what it is so that we can maybe improve the UX. I have no idea what you are doing, but staging only some files or hunks and committing only those totally works, I do this all the time. Can you describe in more detail what exactly you are doing, or maybe even record a screencast?

[acampove]

The version you posted seems to be buggy, when I stage one file and then commit, it commits all the changes, even the non staged ones and even in different files.

@acampove This must be some sort of misunderstanding or usage error, and I'm interested in finding out what it is so that we can maybe improve the UX. I have no idea what you are doing, but staging only some files or hunks and committing only those totally works, I do this all the time. Can you describe in more detail what exactly you are doing, or maybe even record a screencast?

Nevermind, after looking around I found out that this has nothing to do with lazygit. It was caused by a precommit hook that was adding all the files instead of just a subset of them.

[stefanhaller]

This has been released with v0.66.0; closing.