Check out a remote branch with a prefix that doesn't have a local branch created yet, e.g. remotes/origin/features/dx-matters
Observe that a local branch was created with a name dx-matters
Go back to Git GUI, commit any changes, and Push the branch
The cluttered "Push Branches" window pre-selects the dx-matters source branch and selects Destination Repository of origin by default
Actual result:
The user will be notified by their team members that they haven't pushed any changes, and they'll both have to waste time figuring out where are the commits and why doesn't the pull request track them ;)
Both the remotes/origin/features/dx-matters and remotes/origin/dx-matters will exist on the server, despite the user following quite logical steps (by copying an existing remote branch) and preferring to use GUI to avoid such typos (which in most cases includes newbies who don't exactly know the nuances of how do the branch prefixes work and what's the difference between remotes|origin|features if they're all orange in gitk)
Expected result:
The user could be at least notified (with some red text) that no remote tracking branch exists for this branch and it'll be created; at least if there is at least one prefixed branch with a same name & without a conflicting prefix (or am I wrong in assuming that almost nobody prefers to deliberately create such conflicting names?)
In general, visualizing any expected movement of a remote branch could be very beneficial to make Git more intuitive to use, e.g. by saying that "2 new commits will be pushed" (after all, it isn't possible to make a conflict if you don't force push; and of course, it'd be preferable to have even an option to have the push rejected if the remote branch position didn't match the local one; especially if it has been force pushed in the meantime)
In the best case, the gitk could be fixed directly (but they don't provide any public issue tracker, so I have no idea what's their stance about this use-case)
Just like Source Branches, the Destination Repository could also list the "Destination Branches" as a way of selecting an existing branch, which could result in the branch being seemingly renamed before the push
The "Arbitrary Location", or a similar text field of a branch name, could support auto-filling a selected branch name; or even an explicit (namespace) prefix without having to manually type the same branch name again (which would introduce tons of typos)
As another feature request, if the user has to make a temporary tracking branch for the sole purpose of making a push, I could imagine a new checkbox to "Delete the local branch after a successful push" being very useful, considering that the remote branch stays there anyway
Of course, deleting the reference has a risk of the remote branch being removed by someone else's force push, which is a good reason not to enable this by default (and risk getting stuff garbage collected in the future); though personally I'd recommend providing us with a new option to fetch without automatically accepting any force push (until explicitly confirmed)
And in general, please, let's all focus on improving the DeveloperExperience of the stupid content tracker that we all love. There's still so much unnecessary learning curve for new users, yet the UIs have still barely scratched the surface of use-cases beyond simple 'commit & push' :)
Steps to reproduce:
remotes/origin/features/dx-mattersdx-mattersdx-matterssource branch and selects Destination Repository oforiginby defaultActual result:
remotes/origin/features/dx-mattersandremotes/origin/dx-matterswill exist on the server, despite the user following quite logical steps (by copying an existing remote branch) and preferring to use GUI to avoid such typos (which in most cases includes newbies who don't exactly know the nuances of how do the branch prefixes work and what's the difference betweenremotes|origin|featuresif they're all orange in gitk)Expected result:
And in general, please, let's all focus on improving the Developer Experience of the stupid content tracker that we all love. There's still so much unnecessary learning curve for new users, yet the UIs have still barely scratched the surface of use-cases beyond simple 'commit & push' :)