Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Feature request] Display branch names in Gstatus #1700

Open
Gelio opened this issue Mar 16, 2021 · 4 comments · May be fixed by #1713
Open

[Feature request] Display branch names in Gstatus #1700

Gelio opened this issue Mar 16, 2021 · 4 comments · May be fixed by #1713

Comments

@Gelio
Copy link

Gelio commented Mar 16, 2021 •
edited
Loading

Hey,

While working with :Gstatus after a rebase I found it difficult to see which commits are on some existing branch (e.g. origin/master), and which are on my local branch. Example output:

image

The view would certainly be more useful to me if there was a branch name displayed next to commits to which the branches point to, e.g.

image

This would then be similar to how branch names are shown in the regular git log

image
@Gelio Gelio changed the title Display branch names in Gstatus [Feature request ]Display branch names in Gstatus Mar 16, 2021
@Gelio Gelio changed the title [Feature request ]Display branch names in Gstatus [Feature request] Display branch names in Gstatus Mar 16, 2021
@tpope
Copy link
Owner

tpope commented Mar 16, 2021

First things first, I highly recommend using origin/master as your upstream, and setting push.default to current. This will give you an additional 2 sections based on your relation to origin/master which makes it a lot easier to grok what's going on.

That said, this is a good (if obvious) idea. The problem is that we're limited to plain text, so we'd need to make it something like (origin/master) in order to syntax highlight it, and even that isn't good enough because it will match (#1241) in your screenshot. Best we can do is try to make it really weird to avoid false positives. There's a good chance this will happen some day but currently I have enough other experiments going on that I won't be adding this to the pile for the time being.

@Gelio
Copy link
Author

Gelio commented Mar 17, 2021

First things first, I highly recommend using origin/master as your upstream, and setting push.default to current. This will give you an additional 2 sections based on your relation to origin/master which makes it a lot easier to grok what's going on.

That's an interesting approach. Yeah, this definitely makes it easier to see what's the status of the topic branch in relation to the upstream. Thanks for the tip!

Right, I see the potential problems. I guess using some obscure characters (I'm thinking «origin/master») would it less prone to false positives.

Out of curiosity, if it happens that I have a free afternoon, are you open to contributions in this area?

Anyway, thanks for the answer

@tpope
Copy link
Owner

tpope commented Mar 17, 2021

The initial implementation is not the bottleneck, but if you wanna start prototyping and get a feel for what works and what doesn't, have at it. Shouldn't be much more to it than updating s:QueryLog(), s:FormatLog(), and the syntax highlighting.

@Gelio Gelio linked a pull request Mar 24, 2021 that will close this issue
Open
@Gelio
Copy link
Author

Gelio commented Mar 24, 2021

After some experimentation, I produced #1713

heymatthew added a commit to heymatthew/dotfiles that referenced this issue Dec 11, 2023
@heymatthew
feat: Prefer "upstream" push strategy by default
5b57eb2 
Makes it easier to see what's the status of the topic branch in relation
to the upstream.

Highly recommended by tpope
tpope/vim-fugitive#1700 (comment)

Simple has been default since Git 2.0 and is good for beginners.

  upstream - push the current branch back to the branch whose changes
  are usually integrated into the current branch (which is called
  @{upstream}). This mode only makes sense if you are pushing to the
  same repository you would normally pull from (i.e. central workflow).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Show refs in log in Gstatus Gelio/vim-fugitive
3 participants
@tpope @Gelio and others