Depends on #100172

Not the same, mine is about adding things like push/pull/stash and commit options like Commit Staged (Ammend) in a more accessible area.

This new feature display seems a little bit broken with the new insider version I got today, it's way off on the right, there's like a 100px offset between the submenu and its content. I couldn't find any opened issue referencing this new visual problem but it happens on all submenus (I'm on Windows).

Also is there a flag to disable this new view? I prefer the old view, since the new view requires (2x mouse positioning) first is to go over the "pull, push" submenu and second go on the command "push", while previous version is going straight to the command. I do push/pull every day and I find the extra step (mouse positioning) a bit annoying. It would be nice to choose which commands we want as submenu and which one we don't, but a simple flag for the old/new UI would be enough in my case.

Yeah, I have the same issue with the sub-menu alignment. But more importantly, the most common commands have got to be at the top and not under a sub-menu because now I have to click more to get to a common action like doing a push or a rebase.

Yes totally agree and I've mentioned that as well in my previous comment, we now have to do 2 mouse actions (positioning) instead of 1 and that bothers me as well. Hopefully there's a flag or options to customize it?
Waiting for Ms Team to reply on this :)

The submenu positioning was a separate workbench issue which just got resolved in master. I don't think a configuration flag is warranted to display the git menu: it was a big clutter of mess which lacked certain commands. With submenus we can organize commands better and add some missing ones without it looking like a kitchen sink. That sure comes at the cost of you sometimes going one extra level to get where you want to go, but that's expected. There are many other ways to run git commands without the mouse hassle: via F1 and via keyboard shortcuts.

Don't you think that having some of the most commonly used commands at the top of the menu makes sense? It's great that the sub-menus allow it to be more organized and support more commands, but the most common ones should still be easily accessible without digging through the menus IMO.

I have repositories checked out. I'm looking at them, but the top options in the menu that are the easiest to get to are for me to "Checkout to..." and "Clone". Sure seems like there are git actions that are a lot more frequently used than those when I'm already working with a repository. I'm sorry, but don't you think this is a bit ridiculous? I guess maybe this is not the final design and I'm jumping the gun on the criticism here, but I'm just giving my feedback which is what I think this Insiders channel is for.

Ah man it is always tough to change habits. I'm wondering if there is a ux study which showed what menu people preferred? Do you have user data on which menu choices people frequently clicked on? Can you add a push button? Is there a follow up issue to fix @Senko-Dev original issue?

It's not about changing habits. Checkout to... and Clone are now top level options on repos that I am already working with. Please tell me how that makes any sense? There are plenty of git commands that can be buried because they are rarely used, but push, pull, pull (rebase) and maybe stash and pop latest stash are going to be the most common commands when I am working with a repository.

Here is what GitKraken has as top level commands:

please bring back the "Push" button in the top menu... change is hard and I'm lazzz

I don't like that push and pull are hidden in a sub menu now, those are the most used commands and should be on top level.

Fuck it, time to GitHub Desktop.

As a workaround I just published a simple extension.

It's not about changing habits. Checkout to... and Clone are now top level options on repos that I am already working with. Please tell me how that makes any sense?

Agreed, burying common commands in slow flyout menus without a straightforward way to customize is just bad design. Closing related issues as "as designed" is bad customer service. Not everyone wants to keyboard their way to a git push, some of us like to do it differently.