Just as a counter point to all the jubilation, we are using the Umbrella SSO plugin with a GSS/Kerberos protected frontend, This means non of our users have to type in passwords or manage ssh keys, but they do have to use user@ in the url to get the authentication to work correctly. For us this is a breaking change and we will need to add the variable to the properties file to maintain the old behavior. This seems the opposite to how new functionality should be introduced. I'd have liked to see the new variable switch the new behavior on, not off. 

As for the change itself - thank you!  I plan to suggest in my "what you'll get with the upgrade" notes that users who would be affected and might not want to enter their username each time start using SSH keys ahead of the upgrade

Just leverage Git credentials utilities. SSH has nothing to do with this:

• for Windows:
  $ git config --global credential.helper wincred
  which stores the credentials inside the Windows Credentials Store (hit the Windows key and type "Credential Manager" to see what's in there)
  $ git config --global credential.helper “/mnt/c/[Program\ Files/Git/]mingw64/libexec/git-core/git-credential-wincred.exe”
  if you're using WSL
• for Mac:
  $ git config --global credential.helper osxkeychain
  which stores the credentials in the keychain
• for Linux:
  if you're using a Gnome based distro:
  $ git config --global credential.helper gnome-keyring
  which stores the credentials in the Gnome keyring
  or code your own credentials helper and feel the power of open source at the tip of your fingers (see https://www.kernel.org/pub/software/scm/git/docs/technical/api-credentials.html)

If you want to find out which credential helpers are available with your Git setup:
$ git help -a | grep credential-

In last resort, you go with:
$ git config --global credential.helper store
which stores the credentials unencrypted in ~/.git-credentials, see https://www.kernel.org/pub/software/scm/git/docs/git-credential-store.html)

See, username in URLs have never been needed with Git 🤷‍♂️

Kristy - Belated thanks for the pointer.  Yes, I saw it there after I had completed my upgrade analysis planning (but before I upgraded).  In the list it didn't jump out as something that would change end user behavior - I just read it because it looked interesting...

As to your question about "anything extra that I would have liked"...  First let me say I love your release notes format where you highlight new features and list all of the other changes.  It is incredibly useful and I appreciate the amount of time you must spend to get this "end user ready".  I also completely understand that you can't further emphasize every change that you document in the changelog, but I also know that it is hard for someone planning an upgrade to read every change and determine if it will negatively affect them.  My comment was only was that this particular change was more important to know about since it can change the end user experience.  Also, if it ended up causing enough angst that we needed to restore the previous behavior, we would need a restart.  We operate globally and have to count and (justify to senior leadership) every service interruption.  That would be two strikes against us in the end user experience of the upgrade   If it was listed in the summary of the release notes to bring attention to it as part of upgrading to this version, people could make up-front decisions, warn users of what they need to do, etc.

As for the change itself - thank you!  I plan to suggest in my "what you'll get with the upgrade" notes that users who would be affected and might not want to enter their username each time start using SSH keys ahead of the upgrade.  If anyone has run into situations beyond "I don't want to type my username at a prompt", I would be interested so I can maybe cut some of those issues off too.  Thanks!

Hi sandy.motyl1309351599,

I'm sorry that this issue caused you upgrade pain. This issue is already mentioned in the release notes as part of the changelog. Is there anything extra that you would have liked to see in the release notes?

Regards,
Kristy

I just happened upon this when doing some upgrade planning.  It might be helpful if was highlighted as changed behavior in your release notes.  Now that I know this, I will either include in our upgrade impact statements that end users with older versions of git need to either upgrade or manually add the username back into their URLs.  Thanks for your consideration.

@Bryan Turner

Nope, the bitbucket.properties http.cloneurl.includeusername=true will meet my needs.  No further action required on your part.

I just wanted to post a public comment here because I suspect that somebody, somewhere out there is going to upgrade to Bitbucket 5.12.0 and suddenly their RHEL/CentOS users on older git versions will not be able to clone using the provided HTTPS URL given by the web UI.

jeffrey.thornsen,

Is there something specific you'd like to see done for that? You can set http.cloneurl.includeusername=true in bitbucket.properties when you upgrade and Bitbucket Server will continue to include the username in the URL. (You'll also continue to have the auth "errors" from BSERV-9904, but that's the trade-off.)

Is there something else we can do to improve the scenario? When you're browsing the UI the application can't know what version(s) of Git you'll eventually clone with, so it's not possible to conditionally include or exclude the username based on that. Having whether to include the username or not configurable per-user represents a significant amount of work, and is likely to be a poor-to-mediocre "improvement" on the situation--users would still need to know that, for their Git version, they need to opt into including the username, and it would put any improvement on BSERV-9904 in the hands of users (unless we built a way for sysadmins to force the flag one way or another--in which case we're right back to your issue).

Thoughts?

Best regards,
Bryan Turner
Atlassian Bitbucket

I know this issue is somewhat old, but the fix is coming in a new version of Bitbucket Server and I would like to point out that a large number of my users are on Red Hat / CentOS 6 and 7, which ship with fairly old versions of git (1.7.x and 1.8.x).  These versions of git require that you specify the username in HTTPS clone URLs.  Without the username, these versions of git appear to just bomb out and never attempt to ask the user for credentials (well, I know at least my users on RHEL6/CentOS6 had this issue).

Most experienced git users will set up SSH keys anyway, but users who are completely new to git would get confused when the clone URL given to them by the tool (without a username in the HTTPS clone URL) didn't work on their CentOS 6 computer.

Bitbucket Server 5.12 will remove the username from HTTP(S) clone URLs by default. (Related: "git" is still present in SSH clone URLs, and we currently have no plans to remove or replace it.)

If having the username in HTTP(S) clone URLs is important, it can be restored instance wide by setting http.cloneurl.includeusername=true in bitbucket.properties. It is not possible to selectively enable/disable including the username.

Best regards,
Bryan Turner
Atlassian Bitbucket

As others have mentioned having the user name in the URL leads to a flood of unnecessary Auth errors in the case of HTTPS.

A bug has been logged for that issue as well. BSERV-9904