New Release

[jesseduffield]

It's been a while since we cut a release (in no small part to me taking a break over the holiday period).

But we ought to cut one soon.

This issue is for deciding what should go into the next release so that we know what we're working towards.

Some issues/PRs I'd like to get into the next release:

• Support selecting file range in patch builder #3259

• Support range select for removing multiple files from a commit with 'd' #3260

• Show better keybinding suggestions #3203 (pending further discussion)

• In-app release notes #3261

  • Something I've been thinking about is adding a release notes popup after the user updates their version, so that they can be warned about things like keybinding updates. This is especially prescient with the recent range select changes given that cherry pick keybindings have changed and I can imagine that being quite disruptive.

What do we think about the above? And what other issues/PRs do people want in the release? @mark2185 @stefanhaller

[stefanhaller]

I would love to include #3173. It's one of those things that I have been using in my fork for quite a while now, and wouldn't want to live without any more.

#3263 would be good to have because it's nicely complementary to the new 'i' command.

Also, #2936 is ready to be merged and only needs a final ok from you.

#3240 would be nice too (minor thing).

[stefanhaller]

Oh, and #3258 since it's a regression from the last release.

[MariaSolOs]

Is the list above for open issues only? Asking because I would love to see #2993 in the next release :)

[jwhitley]

Is the list above for open issues only? Asking because I would love to see #2993 in the next release :)

Already-merged stuff will go in, pretty much by definition. So the issues listed here are “things to land before the next release is cut”.

Anyhow, I’m game for pitching in on anything here. Feel free to point me at something.

Otherwise, I’ve been pounding on #3227, which may or may not be ready in time, but doesn’t seem vitally urgent. The repo_paths changes took ~10 minutes, but then I took to staring into the void of app-startup call sequence to see if I can also take out VerifyInGitRepo. (answer: yes, but then we’d have the first RepoPaths much earlier in time and what to do with it. Probably implies a “service” that manages retrieval and caching of RepoPaths, which are currently buried down under Gui.)

[jesseduffield]

@jwhitley the only ticket above that's not already assigned is the release-notes one, does that interest you?

Otherwise, I’ve been pounding on #3227, which may or may not be ready in time, but doesn’t seem vitally urgent. The repo_paths changes took ~10 minutes, but then I took to staring into the void of app-startup call sequence to see if I can also take out VerifyInGitRepo. (answer: yes, but then we’d have the first RepoPaths much earlier in time and what to do with it. Probably implies a “service” that manages retrieval and caching of RepoPaths, which are currently buried down under Gui.)

Nice, that sounds reasonable to me

[jesseduffield]

I've put all the above-mentioned issues/PRs into a milestone (https://github.com/jesseduffield/lazygit/milestone/13) and of them, only #3261 remains unassigned. We've hashed out the design for it now, so if anybody wants to pick that up, let me know!

[igor-ramazanov]

@jesseduffield #2868 and #3222, please 🙏