Allow Branches button to take up full middle of toolbar because get truncated pretty early

[jglovier]

Description

The team I working with has a convention of using branch names that follow this format: [gh-username]/[project-name]/[feature-or-fix-title], which can make for pretty long branch names.

This is especially convenient when scanning a list of branches for your current feature branch, such as in this branches tab of the GitHub.com repository with a search param for our team or project name.

The Desktop experience of working with these longer branches is a little less helpful, however – . specifically when glancing to see which branch I'm currently on, something I do frequently when I have several different feature branches in progress:

The truncation kicks in pretty early, so given our convention, I typically don't even get to see my feature name part of the branch.

Suggestion: a floated Fetch origin button

The solution I'd like to propose is a floated (visual description, not technical implementation advice 😉) Fetch origin button that allows for the branch button (and menu dropdown) to occupy the entire full width of the toolbar. E.g.:

This would:

• allow the full branch name to be displayed for most branches, even longer ones
• put the Fetch button (which I would assume is the button most frequently clicked in the navbar) in a very familiar primary call to action location
• open up some extra breathing room in the dropdown to display full branch names there too

There may be some glaring downsides that I'm not considering, too. What might those be?

Not sure how many developers or teams of developers on GH follow a similar pattern of branch naming that produces relatively longer names. Do we have any existing data around average branch name length that might help inform us here?

cc @donokuda @nerdneha

Version

• GitHub Desktop: Version 1.1.1
• Operating system: MacOS 10.13.4

Steps to Reproduce

1. Create a branch with a very long name, for example myusername/myproject/my-new-feature-1
2. Observe that truncation in the branch button cuts off the branch name after a relatively few amount of characters.

Expected Behavior

I would expect to be able to see the entire branch name.

Actual Behavior

I cannot see the full branch name.

Additional Information

Not applicable.

Logs

Not applicable.

[iAmWillShepherd]

Do we have any existing data around average branch name length that might help inform us here?

We don't collect this information in Desktop, but I believe dotcom has this info.

[dbchristopher]

Just wanted to add my support for this feature enhancement. I have to switch to command line every time I want to double check what branch I'm currently on, which is really annoying. Seems like an easy fix to remove a common pain point

[tierninho]

@dbchristopher I agree that surfacing the entire branch name would be useful, however you can always just hover over the branch to see the entire name in the tooltip.

[dbchristopher]

Cool, thanks @tierninho! That's helpful. I guess now that I think about it the bigger annoyance is actually having to select a branch from the dropdown which is also far too narrow to show the complete branch name. I hope that will also be expanded to match the wider button

[tierninho]

Glad it helps! Same workaround for the branch list, just hover:

[cocco3]

This is still a poor user experience to have to hover over everything in a list to find what you're looking for instead of just being able to quickly scan it.

[saylynt]

+1, wider makes so much sense, there's so much wasted space to the right...

[j-f1]

I think the dropdowns should be allowed to expand as much as is needed, like regular menus do on macOS.

[tierninho]

Although this comment applies to a neighboring button, it is inline with the original request, i.e. expand the buttons to expose relevant content.

We are showing an "unknown" metric on the push/pull/fetch button when uploading large files:

I suppose it's a timer, but expanding the button would give the user the relevant information.

[billygriffin]

Hi folks, I wonder if the combination of the tooltip over the current branch and the wider dropdown from #6112 improves on this sufficiently to close this issue?

[dbchristopher]

@billygriffin it's a bit of an improvement, but still seems like there's no reason to limit the size of the dropdown header or content.

I've never coded an electron app so I'm not sure if there are some extra limitations on css rendering. But would it be very much more difficult to just have that branch dropdown button and menu content expand to fill the available window space? Or if it needs to be static, at least bump the width up another 50% from where it's set now?

[dbchristopher]

Just to be clear -- this is what I mean by "button":

It would be nice if that button had a fluid width.

And this is what I mean by "menu content":

It would be nice if that also expanded a bit more, or had some fluid layout settings as well

[cocco3]

Most of my branch names are still truncated, so I didn't even notice the menu was widened in the latest release :)

So is there a specific reason to not allow the button and menu taking up available space?

The code below worked great for me. I also resized the app and everything looked ok. (The commented out properties are things that would have to be removed.)

#desktop-app-toolbar .toolbar-dropdown.branch-button {
    /* width: 230px; */
    flex: 1;
}

.branches-container {
    /* width: 350px; */
}

.branches-container .branches-list {
    /* width: 350px; */
}

[dbchristopher]

@cocco3 💯

[cocco3]

Been nearly a year since the ticket was first opened. Has sufficient data been collected yet? Is there any concern with allowing the button to take up available space? I'd be happy to submit a PR to get this conversation back up.

[billygriffin]

Hi @cocco3, thanks for the friendly nudge. To be honest, while I totally agree that this can be improved, we haven’t heard it enough to prioritize work around it yet. We are discussing it internally and what pitfalls may exist, and I appreciate you following up on it as it helps keep it top of mind with hundreds of things we (or the community) could work on at any point in time. I’ll make sure we get somewhere on how we’d like to go forward here, but there are several other things we’re working on at the moment that we’ve received orders of magnitude more user feedback about, so I can’t promise a timeline. Thanks again!

[martinzugec-ctx]

+1 for this issue. I am dealing with many new contributors to GitHub (people that are not familiar with versioning systems) and we are using automatic branch names that are longer than usual.

This has been extremely confusing to most contributors and I keep hearing this complain almost on a daily basis.

[fabtjar]

We are discussing it internally and what pitfalls may exist

@billygriffin What pitfalls could exist with making the dropdown wider? There's a lot space not being used already isn't there?

[cschreib]

I would like to add that the situation is made much worse when the branch has a PR against it, as the PR number is now taking almost half of this already small space:

In the example above, I'm getting 3 useful characters (we use the [author]-[branch-name] convention at work).

What about making it user-adjustable, like the left panel with the list of files/commits?

[Jeffrey-R]

Most of my branch names are still truncated, so I didn't even notice the menu was widened in the latest release :)

So is there a specific reason to not allow the button and menu taking up available space?

The code below worked great for me. I also resized the app and everything looked ok. (The commented out properties are things that would have to be removed.)

#desktop-app-toolbar .toolbar-dropdown.branch-button {
    /* width: 230px; */
    flex: 1;
}

.branches-container {
    /* width: 350px; */
}

.branches-container .branches-list {
    /* width: 350px; */
}

Using View > Toggle Developer Tools I was able to find the file: /Applications/GitHub Desktop.app/Contents/Resources/app/renderer.css where these changes are made. Thanks @cocco3 for the great tip!

[steveward]

Requested in #16099.

[jgallantgs]

Most of my branch names are still truncated, so I didn't even notice the menu was widened in the latest release :)
So is there a specific reason to not allow the button and menu taking up available space?
The code below worked great for me. I also resized the app and everything looked ok. (The commented out properties are things that would have to be removed.)

#desktop-app-toolbar .toolbar-dropdown.branch-button {
    /* width: 230px; */
    flex: 1;
}

.branches-container {
    /* width: 350px; */
}

.branches-container .branches-list {
    /* width: 350px; */
}

Using View > Toggle Developer Tools I was able to find the file: /Applications/GitHub Desktop.app/Contents/Resources/app/renderer.css where these changes are made. Thanks @cocco3 for the great tip!

Hi I just wanted to +1 this feature and post this for anyone else, as I too use large branch names. I've found this works for me as of today, the 350px is just too small. Thank you @cocco3 and @Jeffrey-R 🥇 Legends!

#desktop-app-toolbar .toolbar-button.branch-toolbar-button {
  min-width: 450px;
}

.branches-container {
  min-width: 450px;
}

.branches-container .branches-list {
  width: 100%;
}

[Jay-o-Way]

LOL almost 5 years later...

[frankhli843]

Hi I wanted to chime in here as well. This CSS change would be much appreciated.

[ihasdapie]

+1 to be able to widen the branch name selector to fit long branch names on github web and github desktop. This is particularly aggravating when using github on any sufficently large team with branching conventions. In particular the web interface doesn't even support having a tooltip that displays the full branch name and the user has to rely on the browser's link preview.

[jpedroso]

This branch in my fork makes the branch dropdown button resizable, in the same way the sidebar is. The branches list also reflects the size of the resizable button and extends to fill its width when opened.

Here’s a demo showing how it behaves with the minimum window size and different zoom values:

2023-10-17-001841.mp4

As for implementation details, the branch toolbar dropdown is wrapped in a Resizable with a maximum width of 600. Default size remains 230 and it conforms to IConstrainedValue. Like other resizables, double-click resets to default width as seen in video.

@tidy-dev what do you think? This might not be too far from your preferred solution in #17388. Let me know if you’d consider opening this issue to contribution.

[jpedroso]

I made a few tweaks in updateResizableConstraints() such that the max width of the branch dropdown button is the available space in the toolbar after taking the sidebar width and the push/fetch button fixed width (230). This prevents the resizable from squeezing the pull/fetch button like shown in previous post.

2023-10-18-001844.mp4

[Jay-o-Way]

Question:
why is the left-most ("repo") button width connected to the side-bar in the first place? This should be independent. The button is not a part of the sidebar.

[tidy-dev]

@jpedroso Thank you for doing this exploration. I responded to your request in #17388 (comment) .

@Jay-o-Way There has been some discussion about refactoring to make it independent. This comment has links where you can read up on that, but is not something we are looking to work on as part of the branches and pull/push/fetch toolbar button work.

[Jeffrey-R]

Thanks for doing this exploration! I would not limit the width of the branch section whatsoever. Let the minimum sizes of the other elements dictate what max size is possible. Very long branch names are easy to encounter when you use a folder structure and make sure you are clear. As long as the other elements are not squeezed I see no reason to not maximize the branch name section. I do that for each new build like this: [image: image.png] It makes the Fetch/Push button stay in the same place which is a nice side effect.

…

On Thu, Oct 19, 2023 at 5:10 AM tidy-dev ***@***.***> wrote: @jpedroso <https://github.com/jpedroso> Thank you for doing this exploration. I responded to your request in #17388 (comment) <#17388 (comment)> . @Jay-o-Way <https://github.com/Jay-o-Way> There has been some discussion about refactoring to make it independent. This comment <#4195 (comment)>has links where you can read up on that, but is not something we are looking to work on as part of the branches and pull/push/fetch toolbar button work. — Reply to this email directly, view it on GitHub <#4569 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHTEDD7JB3ISG7J7NWW6QLYAEKCZAVCNFSM4E5WPMY2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGA4DEMBZGYYA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chronvas]

I made a few tweaks in updateResizableConstraints() such that the max width of the branch dropdown button is the available space in the toolbar after taking the sidebar width and the push/fetch button fixed width (230). This prevents the resizable from squeezing the pull/fetch button like shown in previous post.
2023-10-18-001844.mp4

This looks much better from the current implementation 👍
Can I please ask why isn't this an open PR?

[Jay-o-Way]

Come on, after six years... 😮‍💨

[Jeffrey-R]

I make this change/workaround everytime there is a new release. I even have shared it w/ all my coworkers so they can make it too XP

…

On Fri, Jan 26, 2024 at 8:54 AM Jay ***@***.***> wrote: Come on, after six years... 😮‍💨 — Reply to this email directly, view it on GitHub <#4569 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHTEDBYGELKHLVCYUMJMLTYQPNWDAVCNFSM4E5WPMY2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGIZTONZSGMZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jpedroso]

pr #18095 submitted for this