Similar to what was done in 457cdce61d, and for the same reason.
However, instead of waiting and fixing them one by one as we see them fail, I
decided to go about it more systematically. To do that, I added calls to
`time.Sleep(1 * time.Second)` in all the Shell.Commit* helper functions; this
ensures that all the commits we make get different committer time stamps, making
all these tests fail. With this I'm pretty confident that we're good now.
When entering filtering we would only call FocusLine, which takes care of
highlighting the selected line in the commits list, but not of re-rendering the
main view. HandleFocus does that.
When exiting filtering, the HandleFocus call was missing entirely.
The tests needed to be reworked a little bit to make this testable.
Now that -committerdate is the default sort order, we could get different
results for the sort order of the branches list depending on whether the commits
on both branches have the same committer time stamp (likely in an integration
test, since git time stamps have second resolution), in which case git will fall
back to alphabetical order, or not (rare, but possible), in which case master
will have the newer commit and will come first. Make this stable by forcing the
sort order to alphabetical.
We might have more tests with this problem, we'll just have to fix them one by
one as we see them fail.
As discussed in #4602, we make a general change to how we treat UI
settings that can be changed from within lazygit; previously, the rule
was to persist them in State.yml so that they automatically remember the
last value that was set in the UI; now, we no longer do this, and
instead provide user configs for setting defaults which we fall back to
on every start.
See #4602 for an in-depth discussion about the pros and cons of either
approach, and why we chose this one.
As part of this, we change the default for the sort order of branches to
date (aka committerdate), both for local and for remote branches (was
recency and alphabetical before, respectively). See the discussion
starting
[here](https://github.com/jesseduffield/lazygit/pull/2147#issuecomment-1656700988)
for some reasons.
Fixes#4602.
At the same time, we change the defaults for both of them to "date" (they were
"recency" and "alphabetical", respectively, before). This is the reason we need
to touch so many integration tests. For some of them I decided to adapt the test
assertions to the changed sort order; for others, I added a SetupConfig step to
set the order back to "recency" so that I don't have to change what the test
does (e.g. how many SelectNextItem() calls are needed to get to a certain
branch).
When toggling the value in the UI we simply overwrite the value in UserConfig;
this would be bad if there was ever a chance that we want to write the user
config back to disk, but it is very unlikely that we can do that, because
currently we have no way to tell which parts of the config come from the global
config file and which ones come from a repo-local one.
The version choice is a little arbitrary, but see discussion at
https://github.com/jesseduffield/lazygit/pull/4559#issuecomment-2876201680.
The main reason why I'm updating the version now is that versions before 2.27
had a bug with branch sorting, where sorting by -committerdate (which will be
our default soon) would sort branches that point at the same commit in reverse
alphabetical order rather than alphabetical order. While this is only slightly
annoying but not a huge deal for users, it makes maintaining our integration
tests across versions very hard. So I wanted to update to at least 2.27 to get
around this problem, and went with 2.32 after the discussion linked to above.
The choice of which versions to run integration tests on is pretty arbitrary
too, I just picked some at random which are about 5 to 6 minor versions apart.
- **PR Description**
Doing a hard reset is really destructive because it loses all
uncommitted changes, so add a confirmation in case there are any.
Fixes#3085Fixes#3709Fixes#4688
It's a very common pattern in the code base to have some code that we want to
run either directly, or with a confirmation, depending on some condition. In
most cases this is solved by creating a local helper function that we call
either directly or from within the HandleConfirm of the confirmation; provide a
convenience helper that makes this easier.
These were found by commenting out the initialization of the struct literal in
EnglishTranslationSet.TranslationSet(), and then running
$ punused pkg/i18n/**/*.go
Punused can be installed with `go install github.com/bep/punused@latest`.
The code was copied from StagingController in 0496e3af50, and I did add the new
text in that commit, I just forgot to adapt the code to actually use it.
- **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.
