Visualize local branch heads in commits panel, 2nd approach #2775

stefanhaller · 2023-07-13T17:02:36Z

PR Description

Visualize stacked branches in the commits panel by showing a (*) marker for commits that are the heads of any local branches (except for the current branch, and for main branches). Since we now only do this in case the user actually creates a stack of branches, I'm hoping that it won't be confusing and we don't need a config for it.

New approach based on the suggestion in #2737 (comment).

Please check if the PR fulfills these requirements

Cheatsheets are up-to-date (run go run scripts/cheatsheet/main.go generate)
Code has been formatted (see here)
Tests have been added/updated (see here for the integration test guide)
Text is internationalised (see here)
Docs (specifically docs/Config.md) have been updated if necessary
You've read through your own file changes for silly mistakes etc

jesseduffield

Looking good, left some comments.

One thing I don't get is why when I pull down your branch I'm seeing this:

What's special about b61ca21?

I think it's gonna be important to have documentation that captures why we have this feature, what logic it follows, etc, because admittedly due to not using stacked branches myself I'm not fully grokking the logic.

EDIT: wait I think I get it now: that commit is the head of another branch. I mistakenly thought we'd only show branches which we had explicitly rebased onto (which is impossible to know). This still makes me wonder about why we're excluding certain branches (main branches for example). Like it would be much easier to explain the feature if we just said 'we'll show a marker for any commits that are the head of a local branch'.

If this feature is only for people using stacked branches (which would currently be a minority of users), I'm leaning towards making this configurable again.

pkg/gui/presentation/commits.go

jesseduffield · 2023-07-13T23:06:44Z

pkg/gui/presentation/commits.go

@@ -99,6 +101,14 @@ func GetCommitListDisplayStrings(
 getGraphLine = func(idx int) string { return "" }
 }

+ branchHeadsToVisualize := lo.FilterMap(branches,


I'd make this a set for fast access (especially given how many commits we currently iterate through here)

See 12f4151.

jesseduffield · 2023-07-13T23:16:14Z

pkg/gui/presentation/commits_test.go

@@ -72,6 +74,54 @@ func TestGetCommitListDisplayStrings(t *testing.T) {
 sha2 commit2
 `),
 },
+ {
+ testName: "show local branch head",


I'd be more explicit about what's being tested here. Am I right in saying we're testing to ensure we don't get the marker on a main branch or on the head commit?

Yes; I changed the title in 1032a05.

jesseduffield · 2023-07-13T23:16:41Z

pkg/gui/presentation/commits_test.go

+ sha3 commit3
+ `),
+ },
+ {


Can we also add a test for the git bisect case?

Now that the bisect logic has moved to local_commits_context.go, no we can't. But the bisect/basic.go integration test covers this.

pkg/integration/tests/bisect/basic.go

jesseduffield · 2023-07-13T23:47:43Z

Something that just occurred to me: if nerd icons are enabled, we should show a branch icon instead of (*) because that makes it clearer that we're talking about a branch. Also cuts it down to one character instead of three

jesseduffield · 2023-07-13T23:53:51Z

I also like the idea of still showing main branches but showing it with a different colour e.g. green. I know that we already show that based on the yellow/green commit hashes but:

The yellow/green commit hashes aren't discoverable and we needed to add an entry in the FAQ for them. If we show a green branch icon against the first green commit, which expands to show 'master' when you enlargen the pane, it'll be clearer what's going on.
If there are other main branches you'll be able to see them too (seems wrong to exclude them)
The red/green/yellow approach is currently lossy in that if a commit is both unpushed and not within the main branch all we're told is that it's unpushed. So we may change this in the future if we can rely on the marker to tell us where the main branch is (I'm just spitballing here; we probably won't change it)

EDIT: ah, we're now showing commits as green based on origin/master (by default), not master. That does change things.

Here's what I had in mind though:

EDIT2: Would also be cool to show the upstream of the current branch in its own colour (e.g. red). I think much of the perceived noisyness from the original PR was that we had a bunch of random remote branches that was overwhelming, and there was no way to differentiate the different branches. Here's what it would look like:

stefanhaller · 2023-07-14T06:45:10Z

Thanks for all the feedback; it's so much that I need to find a good way to respond to it. Let me address the fundamental ones first:

Using the branch icon instead of (*). I had tried this before and rejected it again because I thought it just doesn't look pleasant, and also because I found it not distinct enough. But I can run with it for a while locally and see if I can get used to it. Maybe a different color would help make it more distinct in the dark color scheme.
Your initial b61ca21 confusion. This is an interesting one; it's a local branch that shows a big red upstream gone in the branches panel. Since I tend to be anal about cleaning things up, I have never seen these so far. 😄 I'm inclined to filter those out too, to avoid this confusion. (Any commit that has a green sha shouldn't show the icon.)
Showing other branch heads, like main branches or the current branch's upstream. I'm very much against taking this route, because it will result in confusion again about what these mean (especially when nerd fonts are not enabled). Also, I do find the display too noisy with all the added markers, even when they are color coded. I'm worried that we need to make it optional again, and I'm trying hard not to need a config option for this. It also doesn't really add any new information that's not already contained in the sha color coding.

To sum it up: I'm trying to make it so that only people who use stacked branches will ever see these new markers (and they will not be confused about it). If a marker ever shows up in a situation where there's no stack of branches, it's a bug and should be fixed.

I'd also hope that when we do it like this, we don't need user documentation for it, because there will never be a reason for confusion. (Maybe I'm wrong about this.)

jesseduffield · 2023-07-14T12:29:56Z

Fair points. Lemme try to state some assumptions (tell my if you disagree) behind going with your approach:

users who don't use stacked branches will not be bothered by this feature, because they will rarely see the markers. They could see the marker if they coincidentally stacked branches (e.g. cherry picking some commit that was necessary for both branches before starting work) but it won't happen often and if it does, it won't be a big deal
users who do use stacked branches will quickly work out what the markers represent (at least upon expanding the view)
users would never need to see branch heads from before the head of a main branch because if they're in the main branch then they've already been merged.

After thinking about this for a bit, I think these are sensible assumptions, or at least assumptions worth testing by releasing this as default behaviour.

As for users who aren't using nerdfonts, I don't feel great about the (*) marker just because it suggests that upon expansion there's something like (origin/master) which is true but it's also true for a bunch of stuff we're filtering out, so it's not clear that it's referring to stacked branches specifically. Though off the top of my head the only alternative I can think of is 'S' for 'stacked'.

As for my proposed approach of showing all local branches + the upstream of the current branch, I'm still interested in this because:

it covers the stacked branches use case out of the box
it's easier for users to grok
it's particularly useful when doing git log --all where we can no longer rely on the commit hash colours for everything (e.g. for when the remote branch is ahead)

But my proposed approach will definitely have more noise. I'm going to continue playing with my approach locally before raising it again.

So in conclusion let's go ahead with this PR's approach.

stefanhaller · 2023-07-14T14:10:32Z

users who don't use stacked branches will not be bothered by this feature, because they will rarely see the markers.

I would go so far as to replace "rarely" with "never".

They could see the marker if they coincidentally stacked branches (e.g. cherry picking some commit that was necessary for both branches before starting work)

I don't understand how you can coincidentally end up with a stack of branches by cherry-picking, can you elaborate on that?

The only other situation I can imagine where you would see the marker is when you make a copy of a branch. For example, create a new branch off of the tip of an existing one in order to rebase the new one onto "develop" but keep the old one on "master". In that case you would see the marker for either branch as long as both are pointing to the same commit. I could imagine filtering this out too, i.e. never show the marker for a tip commit.

users who do use stacked branches will quickly work out what the markers represent (at least upon expanding the view)

I would replace "work out" by "be delighted that this is finally visualized". 😄

As for users who aren't using nerdfonts, I don't feel great about the (*) marker just because it suggests that upon expansion there's something like (origin/master) which is true but it's also true for a bunch of stuff we're filtering out, so it's not clear that it's referring to stacked branches specifically. Though off the top of my head the only alternative I can think of is 'S' for 'stacked'.

I would prefer a symbol over a letter. I can imagine just * (without the ()), or maybe the bullet symbol.

Still unhappy with the color though. Magenta works ok for (*), but for just * or for the branch symbol it's not distinct enough. What's the orange color for the upstream branch in your screenshot above? Seems like this would work better, though I'm not sure it also would in the light theme.

jesseduffield · 2023-07-14T14:31:01Z

I don't understand how you can coincidentally end up with a stack of branches by cherry-picking, can you elaborate on that?

Sorry, I was basically saying the same thing as you i.e. you're just duplicating a branch (whether by branching off of a branch or cherry-picking its one and only commit across). Cherry picking came to mind but branching off is the more typical case.

I could imagine filtering this out too, i.e. never show the marker for a tip commit.

Yep that's a good idea, and relevant when we're showing the commits of a branch via the branch view (which currently shows the marker on the top commit)

I would replace "work out" by "be delighted that this is finally visualized". 😄

Touche haha

I would prefer a symbol over a letter. I can imagine just * (without the ()), or maybe the bullet symbol.

Still unhappy with the color though. Magenta works ok for (*), but for just * or for the branch symbol it's not distinct enough. What's the orange color for the upstream branch in your screenshot above? Seems like this would work better, though I'm not sure it also would in the light theme.

An asterisk on its own sounds fine to me. The colour I used was bold red (looks orangish thanks to my theme).

stefanhaller · 2023-07-14T16:34:20Z

I could imagine filtering this out too, i.e. never show the marker for a tip commit.

Yep that's a good idea, and relevant when we're showing the commits of a branch via the branch view (which currently shows the marker on the top commit)

Ah, good point about the branch view. This is all wrong now, and needs to be solved differently. Damn.

The thing is that currently I filter out the currently checked-out branch, which is just wrong in the branch view; it needs to filter out the branch that was expanded. So a scenario that shows wrong information now is: you have branch B stacked on top of branch A. Looking at branch B in the branch view while branch A is checked out shows a marker for B's head but not for A's, which is wrong. I'll see if I can find an easy way to fix this, but I think relying on never showing a marker for the tip is not the right way to fix it.

stefanhaller · 2023-07-15T13:05:20Z

I pushed a rebased version that takes a slightly different approach. It passes the name of the current branch into GetCommitListDisplayStrings, and that's the checked-out branch for the local commits panel, but the selected branch when we're in the branches panel. This fixes the problem of showing wrong markers in the branches panel, and it also makes it clearer what the bisect and branch-being-rebased stuff is about.

stefanhaller · 2023-07-17T12:57:14Z

pkg/gui/controllers/helpers/refresh_helper.go

+ // Need to refresh the commits view because the visualization of local
+ // branch heads might have changed
+ if err := self.c.PostRefreshUpdate(self.c.Contexts().LocalCommits); err != nil {
+ self.c.Log.Error(err)
+ }


This is a problem. It causes the main panel to flicker whenever we refresh branches; for example, this happens for every background fetch, every 60s. Sometimes this even causes the main view to scroll back to the top, which is super annoying when you're in the middle of reviewing a branch. Not always though, sometimes it just flickers, which is bad enough though.

@jesseduffield Any suggestions how to do this differently so that it doesn't have this problem?

Is this an existing problem e.g. does this already happen every 60 seconds if the branches view is focused?

No it doesn't (neither on master nor in this branch). But this is a refresh of the local commits view, so it's not surprising that this doesn't flicker when the branches panel is focused.

The solution is to just call HandleRender instead of PostRefreshUpdate; see f1dd64e.

stefanhaller · 2023-07-18T17:56:27Z

I added one more fixup (48f85ec) that is needed to prevent updateRef todos from showing the branch marker.

jesseduffield · 2023-07-19T07:39:42Z

pkg/gui/context/local_commits_context.go

@@ -39,9 +41,32 @@ func NewLocalCommitsContext(c *ContextCommon) *LocalCommitsContext {

 showYouAreHereLabel := c.Model().WorkingTreeStateAtLastCommitRefresh == enums.REBASE_MODE_REBASING

+ currentBranchName := ""
+ if rebasedBranch := c.Model().BranchBeingRebased; rebasedBranch != "" {


I've been working on worktrees lately and I've had a similar need to know what branch a worktree is on, even if it's rebasing or in the middle of a git bisect, because in those cases the branch is considered to be 'owned' by the worktree, even if git worktree list just reports it as having a detached head. For example, you can't check out a branch that's checked out by another worktree, even if that worktree is in a rebase operation with that branch.

So I think we should have a c.Model().CheckedOutBranch to capture all of the stuff that you've added here. That way, I'll be able to update that to support worktrees on my end. Given we're not using BranchBeingRebased anywhere else, we can remove that.

What do you think?

EDIT: would also be good to standardise on a naming convention e.g. 'checked out branch' for the checked out branch which includes when you're mid rebase/bisect, and 'current branch' for the checked out branch excluding rebase/bisect, where nil/blank means you're on a detached head.

EDIT 2: git rev-parse --abbrev-ref HEAD is good for getting the 'current branch' (under the above naming convention), in case it's awkward having to depend on the model for the branches.

Introducing c.Model().CheckedOutBranch makes sense to me, but I wasn't entirely sure how. Here's one version: c05719b. In this case, I still set the member at the end of refreshCommitsWithLimit() like I did before with BranchBeingRebased. Not sure this is the best place to do that. Also, I can't use the other model members in the implementation like I did before (BisectInfo and Branches) because I can't be sure they have been set at this point, so I'm reading the information again here.

An alternative could have been to store branchBeingRebased in Model like I did before (but maybe as a private field), and then have an accessor function for CheckedOutBranch() that computes the result based on that and the other model fields, similar to what I did before in local_commits_context.go. It would be a bit unusual because Model doesn't have any methods right now.

Let me know what your preference is!

stefanhaller · 2023-07-19T16:20:34Z

pkg/gui/controllers/helpers/refresh_helper.go

+ return strings.TrimPrefix(rebasedBranch, "refs/heads/")
+ }
+
+ if bisectedBranch := self.c.Git().Bisect.GetInfo().GetStartSha(); bisectedBranch != "" {


Just noticed that the StartSha is already set right after the first b g or b b, before we're actually on a detached head. I think we also need to check either Started() or Bisecting() but I'm not sure which one (I don't really get the difference).

I'd use Bisecting() because it's only in the bisecting phase where we have a detached head. Started() is for when you've marked one commit as good/bad but you haven't marked the other commit yet, meaning git hasn't started jumping to different commits.

OK, changed in 182b5a8

stefanhaller · 2023-07-19T16:23:13Z

pkg/gui/controllers/helpers/refresh_helper.go

+ // checked out. Note that if we're on a detached head (for reasons other
+ // than rebasing or bisecting, i.e. it was explicitly checked out), then
+ // this will return its sha.
+ if branchInfo, err := self.c.Git().Branch.CurrentBranchInfo(); err == nil {


I'm calling CurrentBranchInfo here because it exists already. It does more than we need though, so I could add a function that calls git rev-parse --abbrev-ref HEAD like you suggested. (CurrentBranchName()?)

Yep, having that as its own function makes sense

See e531aac

stefanhaller · 2023-07-20T07:44:30Z

I'm happy for this to get postponed to after the release, just in case you were wondering. It would feel a bit rushed to try to get it in before.

pkg/gui/context/sub_commits_context.go

stefanhaller · 2023-07-24T20:28:33Z

Going to squash the fixups now to tidy up the branch a bit; the individual fixups are linked from the comments above, so you can still look at them if you want.

We still have the problem that the reflog subcommits view doesn't use the right value for currentBranchName, so it sometimes shows a branch marker for the current head when it shouldn't. I don't see a good way to solve this right now; most of the time, the reflog entries are for the current branch, so it would be better to pass the same value as for the local commits view. However, since it's the reflog for HEAD, not for the current branch, there can be reflog entries that refer to a branch other than the current one. I have no idea how to get at the branch name that was current then. Any ideas?

jesseduffield · 2023-07-24T22:19:25Z

@stefanhaller I would just add a flag for the subcommits view that says whether or not you want to show markers and set it to false for the reflog view: I don't expect anybody would need or want the functionality from there

stefanhaller · 2023-07-25T09:41:39Z

@stefanhaller I would just add a flag for the subcommits view that says whether or not you want to show markers and set it to false for the reflog view: I don't expect anybody would need or want the functionality from there

Tried to do this in feedef9; not sure that's the most elegant way to do it. Do you think we need a test for the reflogs subcommits?

stefanhaller · 2023-07-26T11:04:11Z

I went ahead and added an integration test both for the reflog subcommits view and for the branches subcommits view: 3afa29d. It's in the reflog folder, didn't see a better place to put it.

jesseduffield · 2023-07-26T11:26:17Z

pkg/gui/presentation/commits.go

+ // that are not the current branch, and not any of the main branches. The
+ // goal is to visualize stacks of local branches, so anything that doesn't
+ // contribute to a branch stack shouldn't show a marker.
+ branchHeadsToVisualize := lo.SliceToMap(lo.FilterMap(branches,


you can also use the Set type from my generics package via set.NewFromSlice(...) and then later on go:

} else if branchHeadsToVisualize.Includes(commit.Sha) &&

Up to you

Nice, I forgot about that. Changed in e531245

jesseduffield · 2023-07-26T11:27:35Z

pkg/gui/presentation/commits.go

@@ -289,8 +311,9 @@ func displayCommit(
 } else {
 if len(commit.Tags) > 0 {
 tagString = theme.DiffTerminalColor.SetBold().Sprint(strings.Join(commit.Tags, " ")) + " "
- } else if common.UserConfig.Gui.ExperimentalShowBranchHeads && commit.ExtraInfo != "" {
- tagString = style.FgMagenta.SetBold().Sprint("(*)") + " "
+ } else if _, found := branchHeadsToVisualize[commit.Sha]; found && commit.Status != models.StatusMerged {


I think we should show the asterisk before any tags rather than it be an either-or situation

Agree. ab58efc

jesseduffield · 2023-07-26T11:37:11Z

pkg/gui/controllers/helpers/refresh_helper.go

@@ -249,6 +249,32 @@ func (self *RefreshHelper) refreshCommits() {
 wg.Wait()
 }

+func (self *RefreshHelper) determineCheckoutBranchName() string {


This function doesn't depend on anything outside the git_commands package so I'd move it there

It needs several different git command objects though, so self would have to be *GitCommands, I guess. We don't have precedence for that yet. Should this go into a new file?

I can't see why not

It can't go in the git_commands package, because GitCommands is defined in commands, not git_commands. Unless we import commands from this new file in git_commands, which doesn't seem right to me.

I'm happy to move it somewhere if you make a more concrete suggestion where it should go, I can't figure this out myself. Personally I'd just keep it as a local helper in refresh_helper.go.

jesseduffield · 2023-07-29T09:29:36Z

Hmm that is interesting. This would be solved if stacked branches was a first-class concept in git where you could say 'I'm making a stacked branch here' and then that branch would be updated upon rebases. But alas.

So it sounds like you indeed would want that marker there for the sake of consistency. It is a shame though: for those who aren't using a stacked branches workflow, it will be strange to see that asterisk show up every time you create a new branch off a non-main branch (such as in the examples you describe in that mailing list).

Given this conundrum, what are your thoughts on adding a config option so that users can opt-out of seeing the markers?

stefanhaller · 2023-07-29T10:22:52Z

So it sounds like you indeed would want that marker there for the sake of consistency.

No, not for the sake of consistency. I want it because it hints at a real problem that you need to take care to work around: create a second branch off of an existing one, then try to rebase it away from the first one; this doesn't do what you want, the first one will follow. I want the marker as a reminder that I am in this situation. (Side note: there are no good ways to solve this from within lazygit right now, you need to drop to the command line to do what you want. One way to solve this is to do an interactive rebase, and then allow deleting the update-ref todo command, which is currently not possible. When I'm in this situation, I use : git rebase --edit-todo to do this in an editor.)

Hm, thinking about it, it will only be a problem for people having the rebase.updateRefs config on. So we could consider showing markers for head commits only if that config is on. What do you think?

Given this conundrum, what are your thoughts on adding a config option so that users can opt-out of seeing the markers?

I would really, really like to avoid needing a config for this. An opt-out config wouldn't really help; opt-out configs are useful for things that people are annoyed by, but not for things that people are confused about because they don't understand them. That marker for the head commit is really not annoying, just confusing. And opt-in configs are not discoverable, so people won't know there's a useful feature that they are missing.

jesseduffield · 2023-07-29T11:18:35Z

Hm, thinking about it, it will only be a problem for people having the rebase.updateRefs config on. So we could consider showing markers for head commits only if that config is on. What do you think?

I think that's a great idea.

I would really, really like to avoid needing a config for this. An opt-out config wouldn't really help; opt-out configs are useful for things that people are annoyed by, but not for things that people are confused about because they don't understand them. That marker for the head commit is really not annoying, just confusing. And opt-in configs are not discoverable, so people won't know there's a useful feature that they are missing.

I think the rebase.updatRefs config option is the way to go for this situation but I'll respond in the abstract:

I agree on opt-in configs not being discoverable
I disagree about the annoyance/confusion dichotomy: you can be annoyed by something without being confused by it: if I'm somebody who never uses stacked branches but sees that cyan asterisk whenever I create a new branch suggesting that there's something important to note, it can indeed be annoying even if I know what it's trying to tell me.

stefanhaller · 2023-07-29T18:46:47Z

Hm, thinking about it, it will only be a problem for people having the rebase.updateRefs config on. So we could consider showing markers for head commits only if that config is on. What do you think?

I think that's a great idea.

I added 068fbf3 to do that, please take a look.

jesseduffield

LGTM. Doesn't need to be in this PR but it would be good to have an entry about this in the docs explaining what the cyan asterisk represents

stefanhaller · 2023-07-30T09:05:12Z

LGTM. Doesn't need to be in this PR but it would be good to have an entry about this in the docs explaining what the cyan asterisk represents

Happy to add that, but I'm having trouble deciding where it should go. Any suggestions? It doesn't look like we have an existing file in docs where it would fit, so it seems we need to add a new file.

One option would be to add a file about working with stacked branches; explaining the rebase.updateRefs option and some general workflows.

Another option might be to add a file listing useful git options that people may want to set (e.g. "commit.verbose", "push.useForceIfIncludes", "rebase.updateRef"), and then the paragraph about updateRef could explain the asterisk.

Any preference?

jesseduffield · 2023-07-30T09:34:42Z

I prefer the first option: have a file specific to stacked branches. The important thing is that we include the term 'cyan asterisk' so that it's searchable!

stefanhaller · 2023-07-30T12:49:23Z

I added some documentation in ebbe005. There's a lot more to be said about stacked branches, but I kept it brief for now.

stefanhaller · 2023-07-30T12:50:54Z

If you could have a look at #2845 next, that would be appreciated; it's a prerequisite for merging this one.

jesseduffield

LGTM! Great work

We are going to replace it with a better one later in this branch.

This test not only tests the correct handling and display of the updateRef command, but also the visualization of branch heads in the commits panel. Since we are about to change the behavior here, extend the test so that a master commit is added (we don't want this to be visualized as a branch head), and then a stack of two non-main branches. At the end of this branch we only want to visualize the head commit of the first.

This allow us to check not only whether a given commit has the branch head marker, but also that other commits _don't_ have it, which is important.

- check out a non-main branch before we start - add authors to expected commits so that we can see whether the commits show an asterisk - explicitly check what the top line displays after bisecting has started This shows that the detached head shows an asterisk, which we don't want. We'll fix that in the next commit.

The model will be used for logic, so the full hash is needed there; a shortened hash of 8 characters might be too short to be unique in very large repos. If some view wants to display a shortened hash, it should truncate it at presentation time.

We want to mark all local branch heads with a "*" in the local commits panel, to make it easier to see how branches are stacked onto each other. In order to not confuse users with "*" markers that they don't understand, do this only for the case where users actually use stacked branches; those users are likely not going to be confused by the display. This means we want to filter out a few branch heads that shouldn't get the marker: the current branch, any main branch, and any old branch that has been merged to master already.

It's tricky to get this right for reflog commits wrt what's the current branch for each one; so just disable it entirely here, it's probably not something anybody needs here.

jesseduffield · 2023-07-31T07:39:10Z

@stefanhaller I'm seeing cyan asterisks when I run:

go run cmd/integration_test/main.go cli --slow pkg/integration/tests/branch/rebase_and_drop.go

But there's nothing in that test configuring to use updateRefs. Bug?

stefanhaller · 2023-07-31T07:48:43Z

No, that's not a bug. The logic to depend on the updateRef config for showing asterisks was only put in for the head commit. For other commits we always show the asterisk, because it should be useful even for people who don't use rebase.updateRefs, but keep their stacks up to date manually by using rebase --onto.

[![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Update | Change | |---|---|---| | [GoogleContainerTools/skaffold](https://github.com/GoogleContainerTools/skaffold) | patch | `v2.6.2` -> `v2.6.3` | | [ajeetdsouza/zoxide](https://github.com/ajeetdsouza/zoxide) | patch | `v0.9.1` -> `v0.9.2` | | [aquaproj/aqua-registry](https://github.com/aquaproj/aqua-registry) | patch | `v4.32.0` -> `v4.32.2` | | [jesseduffield/lazygit](https://github.com/jesseduffield/lazygit) | minor | `v0.39.4` -> `v0.40.0` | | [weaveworks/eksctl](https://github.com/weaveworks/eksctl) | minor | `v0.150.0` -> `v0.151.0` | --- ### Release Notes <details> <summary>GoogleContainerTools/skaffold (GoogleContainerTools/skaffold)</summary> ### [`v2.6.3`](https://github.com/GoogleContainerTools/skaffold/releases/tag/v2.6.3): Release [Compare Source](https://github.com/GoogleContainerTools/skaffold/compare/v2.6.2...v2.6.3) ##### v2.6.3 Release - 2023-08-04 **Linux amd64** `curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/v2.6.3/skaffold-linux-amd64 && chmod +x skaffold && sudo mv skaffold /usr/local/bin` **Linux arm64** `curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/v2.6.3/skaffold-linux-arm64 && chmod +x skaffold && sudo mv skaffold /usr/local/bin` **macOS amd64** `curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/v2.6.3/skaffold-darwin-amd64 && chmod +x skaffold && sudo mv skaffold /usr/local/bin` **macOS arm64** `curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/v2.6.3/skaffold-darwin-arm64 && chmod +x skaffold && sudo mv skaffold /usr/local/bin` **Windows** https://storage.googleapis.com/skaffold/releases/v2.6.3/skaffold-windows-amd64.exe **Docker image** `gcr.io/k8s-skaffold/skaffold:v2.6.3` **Full Changelog**: GoogleContainerTools/skaffold@v2.6.2...v2.6.3 </details> <details> <summary>ajeetdsouza/zoxide (ajeetdsouza/zoxide)</summary> ### [`v0.9.2`](https://github.com/ajeetdsouza/zoxide/releases/tag/v0.9.2): 0.9.2 [Compare Source](https://github.com/ajeetdsouza/zoxide/compare/v0.9.1...v0.9.2) ##### Added - Short option `-a` for `zoxide query --all`. ##### Fixed - PowerShell: use `global` scope for variables / functions. </details> <details> <summary>aquaproj/aqua-registry (aquaproj/aqua-registry)</summary> ### [`v4.32.2`](https://github.com/aquaproj/aqua-registry/releases/tag/v4.32.2) [Compare Source](https://github.com/aquaproj/aqua-registry/compare/v4.32.1...v4.32.2) [Issues](https://github.com/aquaproj/aqua-registry/issues?q=is%3Aissue+milestone%3Av4.32.2) | [Pull Requests](https://github.com/aquaproj/aqua-registry/pulls?q=is%3Apr+milestone%3Av4.32.2) | aquaproj/aqua-registry@v4.32.1...v4.32.2 ##### Fixes [#14327](https://github.com/aquaproj/aqua-registry/issues/14327) Rename kyleconroy/sqlc to sqlc-dev/sqlc as of repository migration [@ichizero](https://github.com/ichizero) [#14339](https://github.com/aquaproj/aqua-registry/issues/14339) sqlc-dev/sqlc: Support old versions ### [`v4.32.1`](https://github.com/aquaproj/aqua-registry/releases/tag/v4.32.1) [Compare Source](https://github.com/aquaproj/aqua-registry/compare/v4.32.0...v4.32.1) [Issues](https://github.com/aquaproj/aqua-registry/issues?q=is%3Aissue+milestone%3Av4.32.1) | [Pull Requests](https://github.com/aquaproj/aqua-registry/pulls?q=is%3Apr+milestone%3Av4.32.1) | aquaproj/aqua-registry@v4.32.0...v4.32.1 #### Fixes [#14275](https://github.com/aquaproj/aqua-registry/issues/14275) [#14276](https://github.com/aquaproj/aqua-registry/issues/14276) [#14277](https://github.com/aquaproj/aqua-registry/issues/14277) [#14278](https://github.com/aquaproj/aqua-registry/issues/14278) [domoritz/arrow-tools/{csv2arrow,csv2parquet,json2arrow,json2parquet}](https://github.com/domoritz/arrow-tools): Follow up changes of asset names </details> <details> <summary>jesseduffield/lazygit (jesseduffield/lazygit)</summary> ### [`v0.40.0`](https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0) [Compare Source](https://github.com/jesseduffield/lazygit/compare/v0.39.4...v0.40.0)  ### 🎉 LAZYGIT FIVE YEAR ANNIVERSARY EDITION 🎉 Holy moly, has it really been 5 years since Lazygit's birth? Time flies when you're having fun. I've written a post celebrating the anniversary [here](https://jesseduffield.com/Lazygit-5-Years-On). As for this release, we've got some great features here. ##### Worktrees We now have a worktrees view so you can easily create worktrees and switch to them and so on. I'm not a big worktrees user myself so please raise an issue if you can think of places to improve the UX. ![worktree_create_from_branches-compressed](https://github.com/jesseduffield/lazygit/assets/8456633/3ef0b085-e9d0-42de-af58-16cbae581d34) ##### Rebase --onto Rebasing onto a marked base commit is a very useful feature that we've been sorely lacking for a while (demo coming soon) ##### Auto-refresh on window focus Auto-refresh on window activation is a complete game-changer. No more having to manually press shift+R when you come back from your editor. ##### Nuking the worktree We also have a fun enhancement in this release: showing an explosion animation when you nuke the working tree. ![nuke-gif](https://github.com/jesseduffield/lazygit/assets/8456633/32b3f91c-fea3-474d-8997-1de2f5e4f5d4) You'll also notice in the readme we've got some updated demo gifs to showoff Lazygit's features. More of those to come. #### What's Changed ##### Features ✨ - Add worktrees view by [@jesseduffield](https://github.com/jesseduffield) (with help from [@kadaan](https://github.com/kadaan)) in [jesseduffield/lazygit#2147 - Rebase onto branch from a marked base commit by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2835 - Auto-refresh on window activation by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2854 ##### Enhancements 🔥 - Faster refresh by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2841 - feat: add os.copyToClipboardCmd to allow for a custom command [#1055](https://github.com/jesseduffield/lazygit/issues/1055) by [@redstreet](https://github.com/redstreet) in [jesseduffield/lazygit#2784 - Add bisect menu entry that lets you choose bisect terms by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2838 - When bisecting, always mark the current commit as good/bad, not the selected by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2837 - Visualize local branch heads in commits panel, 2nd approach by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2775 - Allow force-tagging if tag exists by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2827 - Save IgnoreWhitespaceInDiffView in state.yml by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2830 - Show loader when rebasing by [@KarlHeitmann](https://github.com/KarlHeitmann) in [jesseduffield/lazygit#2851 - Internationalise logging of commands by [@KarlHeitmann](https://github.com/KarlHeitmann) in [jesseduffield/lazygit#2852 - Show visual explosion effect when nuking worktree by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2861 ##### Fixes 🔧 - Fix issue where using `null` to un-map a keybinding was ignored by [@hatredholder](https://github.com/hatredholder) in [jesseduffield/lazygit#2832 - Show error when trying to open patch menu with an empty patch by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2829 - Fix merge status for update-ref command by [@stefanhaller](https://github.com/stefanhaller) in [jesseduffield/lazygit#2845 - Stop worktrees view from stealing the window by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2863 - Fix confirmation view sizing by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2879 ##### Maintenance ⚙️ - Standardise on using lo for slice functions by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2846 - Remove redundant secureexec package by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2847 - Add automated demo recordings by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2853 - Remove file watcher code by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2865 - Add more demos to the README by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2866 - Move features to top of readme by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2867 - Add more demos by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2874 ##### Other Changes - Create demo output dir if it doesn't already exist by [@jesseduffield](https://github.com/jesseduffield) in [jesseduffield/lazygit#2857 #### New Contributors - [@hatredholder](https://github.com/hatredholder) made their first contribution in [jesseduffield/lazygit#2832 - [@redstreet](https://github.com/redstreet) made their first contribution in [jesseduffield/lazygit#2784 - [@kadaan](https://github.com/kadaan) made their first contribution in [jesseduffield/lazygit#2147 - [@KarlHeitmann](https://github.com/KarlHeitmann) made their first contribution in [jesseduffield/lazygit#2851 **Full Changelog**: jesseduffield/lazygit@v0.39.4...v0.40.0 </details> <details> <summary>weaveworks/eksctl (weaveworks/eksctl)</summary> ### [`v0.151.0`](https://github.com/eksctl-io/eksctl/releases/tag/v0.151.0): eksctl 0.151.0 (permalink) [Compare Source](https://github.com/weaveworks/eksctl/compare/0.150.0...0.151.0) ### Release v0.151.0 #### 🚀 Features - Support custom AMIs for self-managed Windows nodegroups ([#6804](https://github.com/weaveworks/eksctl/issues/6804)) - Support custom Ubuntu AMIs for EKS-managed nodegroups ([#6850](https://github.com/weaveworks/eksctl/issues/6850)) #### 🎯 Improvements - Remove support for EKS 1.22 ([#6704](https://github.com/weaveworks/eksctl/issues/6704)) #### 🐛 Bug Fixes - Fix error with tar in `Post Cache go-build and mod` step ([#6840](https://github.com/weaveworks/eksctl/issues/6840)) - Fix setting link-time variables for release version ([#6841](https://github.com/weaveworks/eksctl/issues/6841)) - Select one subnet for AZs where multiple are present and no VPC config provided ([#6814](https://github.com/weaveworks/eksctl/issues/6814)) - Paginate instance type offerings response ([#6832](https://github.com/weaveworks/eksctl/issues/6832)) #### 🧰 Maintenance - Bump dependencies ([#6852](https://github.com/weaveworks/eksctl/issues/6852), [#6859](https://github.com/weaveworks/eksctl/issues/6859)) - Cleanup Flux Integration ([#6836](https://github.com/weaveworks/eksctl/issues/6836)) #### Acknowledgments Weaveworks would like to sincerely thank: [@watany-dev](https://github.com/watany-dev) </details> --- ### Configuration 📅 **Schedule**: Branch creation - "after 4pm on thursday" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/scottames/dots).  Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

stefanhaller marked this pull request as ready for review July 13, 2023 17:02

stefanhaller mentioned this pull request Jul 13, 2023

Visualize local branch heads in commits panel #2737

Closed

jesseduffield reviewed Jul 13, 2023

View reviewed changes

stefanhaller force-pushed the visualize-local-branch-heads-2 branch from ff7f7b2 to 1032a05 Compare July 15, 2023 13:01

stefanhaller commented Jul 17, 2023

View reviewed changes

jesseduffield reviewed Jul 19, 2023

View reviewed changes

stefanhaller force-pushed the visualize-local-branch-heads-2 branch from 48f85ec to c713c08 Compare July 19, 2023 16:07

stefanhaller commented Jul 19, 2023

View reviewed changes

stefanhaller commented Jul 21, 2023

View reviewed changes

pkg/gui/context/sub_commits_context.go Show resolved Hide resolved

stefanhaller force-pushed the visualize-local-branch-heads-2 branch 2 times, most recently from 990c255 to baaad2f Compare July 24, 2023 20:28

stefanhaller added the enhancement New feature or request label Jul 25, 2023

jesseduffield reviewed Jul 26, 2023

View reviewed changes

stefanhaller force-pushed the visualize-local-branch-heads-2 branch from 7a817a0 to 068fbf3 Compare July 29, 2023 18:45

stefanhaller force-pushed the visualize-local-branch-heads-2 branch from 068fbf3 to b565817 Compare July 30, 2023 08:48

jesseduffield approved these changes Jul 30, 2023

View reviewed changes

stefanhaller force-pushed the visualize-local-branch-heads-2 branch from b565817 to ebbe005 Compare July 30, 2023 12:47

jesseduffield approved these changes Jul 30, 2023

View reviewed changes

stefanhaller added 10 commits July 31, 2023 08:34

Remove the old experimentalShowBranchHeads mechanism and config

9c57444

We are going to replace it with a better one later in this branch.

Add author short names to commits in test

eb6f089

This allow us to check not only whether a given commit has the branch head marker, but also that other commits _don't_ have it, which is important.

Add CheckedOutBranch to Model struct

092d5dd

Store full sha in branch model

0c07963

The model will be used for logic, so the full hash is needed there; a shortened hash of 8 characters might be too short to be unique in very large repos. If some view wants to display a shortened hash, it should truncate it at presentation time.

Don't show branch heads in reflog subcommits

f5c9764

It's tricky to get this right for reflog commits wrt what's the current branch for each one; so just disable it entirely here, it's probably not something anybody needs here.

Don't show branch marker for head commit unless updateRefs config is on

4eb7339

Add documentation for working with stacked branches

94daf7b

stefanhaller force-pushed the visualize-local-branch-heads-2 branch from ebbe005 to 94daf7b Compare July 31, 2023 06:35

stefanhaller merged commit a6af31a into master Jul 31, 2023
12 checks passed

stefanhaller deleted the visualize-local-branch-heads-2 branch July 31, 2023 06:40

stefanhaller mentioned this pull request Jul 31, 2023

Better visualization of branch heads in non-expanded commits view #2735

Closed

Visualize local branch heads in commits panel, 2nd approach #2775

Visualize local branch heads in commits panel, 2nd approach #2775

Conversation

stefanhaller commented Jul 13, 2023

jesseduffield left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jesseduffield commented Jul 13, 2023 • edited

jesseduffield commented Jul 13, 2023 • edited

stefanhaller commented Jul 14, 2023

jesseduffield commented Jul 14, 2023

stefanhaller commented Jul 14, 2023

jesseduffield commented Jul 14, 2023

stefanhaller commented Jul 14, 2023

stefanhaller commented Jul 15, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanhaller commented Jul 18, 2023

jesseduffield Jul 19, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanhaller commented Jul 20, 2023

stefanhaller commented Jul 24, 2023

jesseduffield commented Jul 24, 2023

stefanhaller commented Jul 25, 2023

stefanhaller commented Jul 26, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jesseduffield commented Jul 29, 2023

stefanhaller commented Jul 29, 2023

jesseduffield commented Jul 29, 2023

stefanhaller commented Jul 29, 2023

jesseduffield left a comment

Choose a reason for hiding this comment

stefanhaller commented Jul 30, 2023

jesseduffield commented Jul 30, 2023

stefanhaller commented Jul 30, 2023

stefanhaller commented Jul 30, 2023

jesseduffield left a comment

Choose a reason for hiding this comment

jesseduffield commented Jul 31, 2023

stefanhaller commented Jul 31, 2023

jesseduffield left a comment •

edited

jesseduffield commented Jul 13, 2023 •

edited

jesseduffield commented Jul 13, 2023 •

edited

jesseduffield Jul 19, 2023 •

edited