See divergence from base branch

[stefanhaller]

See divergence from base branch

[stefanhaller]

I hacked on this a bit, and I came up with something that I already don't want to miss any more:

Yes, it's very noisy, but it's also so useful that I think it's totally worth it, at least for me. I'm happy to make it optional, but I'm pretty sure I would leave it on, always.

Of course this will look a lot worse if you have a large number of stale branches. In one of my work repos I have some 50 local branches or more, and many of them I haven't touched for years, so they have fallen behind their base branch by a 5- or even 6-figure number of commits. It doesn't bother me though, on the contrary: it gives me a better sense of how old my branches are than the 8M age display on the left.

@jesseduffield Very keen to hear you thoughts on all this before I spend more time on it.

[jesseduffield]

I like what I'm seeing in that screenshot: the use of blue makes it less noisy than it otherwise would be.

It's also less noisy than what I had assumed was a solution to the problem which is having commit hashes against each branch with the green/yellow/red colouring. I believe showing the ahead/behind count basically gives us all the same information plus more (i.e. 'is this branch fully merged into the base branch so I can delete it', 'do I need to rebase onto the base branch').

Pending testing this feature out myself I'd be happy to make it appear by default.

[stefanhaller]

(i.e. 'is this branch fully merged into the base branch so I can delete it', 'do I need to rebase onto the base branch').

In the current state of my hack it only gives you the second of these, not the first. In order to have the first as well, we'd have to show both the ahead and behind counts; currently I only show behind, to reduce the noise.

Showing both would look like this:

I admit that the ahead information is also useful, not only to tell whether the branch is merged already, but also to tell how long each branch is, which could be useful to know. However, this is really becoming so noisy that the usefulness doesn't outweigh it for my taste.

And btw, the indication of whether the branch is fully merged wouldn't always be accurate, anyway: if a maintainer rebases and force-pushes your branch in order to merge it (like we often do here), then your local branch would still show as unmerged until you pull it.

Later today I'll try to clean up my branch enough so that I can dare post it as a draft PR for testing.

[stefanhaller]

OK, no draft PR yet, but a branch to try out if you want. I have a stack of three branches, and it's probably going to be three PRs in the end, but rebase-onto-base-branch is the top one if you want to test the whole package. It contains the display in the branches list, the "View divergence from base branch" command in the upstream menu, and the "Rebase onto base branch" command in the rebase menu.

For the display, I introduced a config that lets you choose between showing none, only the behind count, or behind and ahead counts. This is only for easier testing for now, I'm not sure yet if we will have a config in the end.

[jesseduffield]

@stefanhaller nice. It's definitely noisy. I'll give it a go for a couple days to see how I adjust.

As for the divergence keybinding: I don't think that belongs in the upstream menu, because iirc the base branch is not necessarily a remote branch. What do you think about having this live in the diffing menu? We can also have the other divergence options live there (in addition to where it currently lives)

[stefanhaller]

I don't think that belongs in the upstream menu. What do you think about having this live in the diffing menu?

Interesting, we already discussed this back when I added the divergence from upstream command. My opinion from back then still holds for this one too. Also, currently the diffing menu only contains commands that enter diffing mode, so this one would be out of place there for this reason alone.

As for the upstream menu: you are right that the base branch is not technically the upstream in the narrow technical sense in which git uses the term (i.e. feature@{upstream}). However, you could still argue that conceptually, the base branch is the next level of "upstream" after the remote tracking branch, so for me it still makes some sense to put it there.

[jesseduffield]

I vaguely recalled that we may have discussed this before. I'm happy to go with that and see how users find it