- **PR Description**
If the hunk to be selected was partially scrolled offscreen, the view wouldn't
scroll enough to make it completely visible (the last line of the hunk was still
offscreen).
If the hunk to be selected was partially scrolled offscreen, the view wouldn't
scroll enough to make it completely visible (the last line of the hunk was still
offscreen).
This is only a minimal fix for a pressing problem. The code to handle scrolling
after selection changes has lots of problems, and is also inconsistent between
list views and the patch explorer, but cleaning this up needs more time than I
have right now.
Globally ignoring all dot files and then making exceptions as needed to pull
files back in again is very error prone. It's better to explicitly exclude
everything we want to hide.
The reason why this came up is that I tried to look at the git history of one of
the files in .github/workflows/ using lazygit's path filtering feature, but it
didn't show up in the list of suggestions. It took me a while to realize that
that's because this list doesn't show git-ignored files. Now, .github/workflows/
wasn't really git-ignored because it was brought back by an exclamation mark
entry in the Exceptions section; but maybe the library we are using to get the
files doesn't handle these properly or something (I didn't further research
this).
Globally ignoring all dot files and then making exceptions as needed to pull
files back in again is very error prone. It's better to explicitly exclude
everything we want to hide.
This can be seen in the vendor directory, where we omitted a lot of files
accidentally (we'll fix that in the next commit). None of these were important,
so no harm done, but still.
The reason why this came up is that I tried to look at the git history of one of
the files in .github/workflows/ using lazygit's path filtering feature, but it
didn't show up in the list of suggestions. It took me a while to realize that
that's because this list doesn't show git-ignored files. Now, .github/workflows/
wasn't really git-ignored because it was brought back by an exclamation mark
entry in the Exceptions section; but maybe the library we are using to get the
files doesn't handle these properly or something (I didn't further research
this).
The core homebrew formular is usually up to date very quickly, so
there's little reason to use the custom tap.
We still maintain the tap and update it for the benefit of users who
already subscribed to it, but we no longer recommend it for new users.
The core homebrew formular is usually up to date very quickly, so there's little
reason to use the custom tap.
We still maintain the tap and update it for the benefit of users who already
subscribed to it, but we no longer recommend it.
- **PR Description**
Make the action run only in my fork, so that releases appear to be
created by me.
Also, update goreleaser to the latest version, and some other tweaks.
As far as I can tell, this is the only way to make sure that releases show up as
created by me. Also, we totally don't want it to run in other people's forks
(although it would likely just have failed there, but still).
The restriction only applies to scheduled runs; manually triggering the action
is still possible from everywhere. There needs to be a personal access token
named LAZYGIT_RELEASE_PAT configured on the repo for this to work, though.
- **PR Description**
This PR fixes the broken markdown table formatting in the auto-generated
keybindings documentation files by properly escaping newlines in
tooltips.
Issue: https://github.com/jesseduffield/lazygit/issues/4689
- **PR Description**
As of #4684, hunk mode has become so useful that I prefer it over line
mode now. This PR adds a config that lets you use hunk mode by default
in the staging view.
I'm not enabling this by default yet, although I do think it's the more
useful mode for most people. The biggest issue that I still have with
this is that _if_ you need to switch to line mode for some reason, then
it's very non-obvious how to do that. New users might not find out at
all, and think that lazygit doesn't allow staging individual lines.
- **PR Description**
Hunk selection mode is one of the features that many people don't know
about, because it is not very discoverable. You can switch to it from
line selection mode by pressing `a` in the staging view.
The problem with this mode is that it selects entire hunks, where hunks
are defined to be sections of the diff starting with `@@`. Very often,
hunks consist of multiple distinct blocks of changes, separated by
context lines. For example, with the default diff context size of 3 it
takes at least 6 unchanged lines between blocks of changes for them to
be separated into distinct hunks; if there are 5 or less unchanged lines
between them, they are grouped into one hunk. And of course, if you
increase the diff context size by pressing `}`, you will get even fewer
hunks.
Now, most of the time I want to navigate between the individual blocks
of changes in a diff, regardless of how git groups them into hunks.
That's what this PR does: when pressing `a`, the selection is extended
to just the current group of changes, separated by context lines; you
can easily stage it by pressing space, and the selection will move on to
the next block of changes. Actual hunks no longer play a role here.
Also, in line selection mode the right/left arrow keys now move between
blocks of changes rather than actual hunks.
I find this new behavior so useful that I almost always switch to hunk
mode right away after entering the staging view. It saves a lot of
keystrokes, since it is very rare that I want to select only some lines
of a block of adjacent changes. This makes me wonder whether we should
enable hunk mode by default when entering staging, but that's going to
be another PR.
It's annoyingly slow, and there is a separate task for generating the list if
needed.
Also, clear the terminal before running the test; this makes it easier to see
the results of the last test run.
We only want to do this when the function is called from the remote branches
panel. It can also be called with a selection of local branches in order to
delete their remote branches, but in this case the selection shouldn't be
collapsed because the local branches stay around.
We had code already that was supposed to do this, but it didn't work. It should
have used SetSelection() instead of SetSelectedLineIdx(); the latter doesn't
actually cancel a range selection.
Introduce a new function specifically for collapsing the range after deleting
multiple items, so that clients don't need two calls (we'll add a bunch more in
this branch).
- **PR Description**
While it's true that the behavior is a little different from the staging
panel, where the staged lines are actually removed from the view and in
many cases the selection stays more or less in the same place, it is
still very useful to move to the next stageable thing in the custom
patch building view too.
Also, we change the visualization of what's included in the patch to
mark only the + and - lines of the patch; for all other lines it doesn't
make a difference whether they are included.
And finally, we make it so that only + and - lines are considered when
pressing space; previously it would also look at selected context lines,
which doesn't make much sense. This improves the experience for mouse
users who like to generously select hunks by dragging across them,
including some context lines above and below.
While it's true that the behavior is a little different from the staging panel,
where the staged lines are actually removed from the view and in many cases the
selection stays more or less in the same place, it is still very useful to move
to the next stageable thing in the custom patch building view too.
This improves the experience when selecting a hunk generously with the mouse, by
dragging over it including some context lines above and below. Previously we
would consider the "moving end" of the selection range for whether things need
to be added or removed, but this doesn't make sense if it's a context line. Now
we consider the first actual change line that is included in the range.
