jredmond Atlassian Team

You'll need either to rename the existing creditntellimages repo to "creditntell.bitbucket.io" or to create a new repo by that name.

Is `creditntellimages` your username?

Both of those go to bitbucket.org, but the second one includes the username. That isn't necessary for browser access, as your user session is managed by the login process.

Yes, this does look like a DNS issue. Can you reach Bitbucket from a browser on that system?

The label in an SSH public key has no effect on the key function. It's only there for humans to tell keys apart.

The label in an SSH public key doesn't affect the key's function - it's only there so humans can tell keys apart, and it's safe to remove if you want.

The URLs for repos have not changed, nor have the usernames used to authenticate for Git or Mercurial transactions. The only place the email address factors in is GUI authentication.

Curious, but are you attempting to use https://accountname.bitbucket.io, or are you using your own account name?

We have a mail service but it is strictly for internal use.

Are you asking about Bitbucket Cloud (bitbucket.org) or Bitbucket Server?

Are you using a proxy? Does DNS report a correct IP for bitbucket.org? Is there a firewall that needs to permit outgoing connections to Bitbucket?

You've provided the base URL to the Bitbucket Server instance, but you need to add the rest of the path for the repository you want to import. You may also need to check the "requires authentication" box.

It won't work if the user attempting to push directly to master doesn't have permission to push directly to master. The contents of the push and the existence of a pull request aren't really relevant in that case.

You need to focus on the Bitbucket credentials being used to authenticate - either the username in https://username@bitbucket.org/owner/repo, or the account associated with your SSH key. As I've said before, the git committer name and email are not relevant to Bitbucket permissions.

Ah, I think I see the reason you were getting a different answer than you wanted: you're asking about forks, not clones.

Yes, repos are backed up: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repository-288658413.html However, you should also remember something else about Git and Mercurial: One of the great features of distributed version control systems (DVCS) such as Git and Mercurial is that they're distributed.…

You're looking at the wrong documentation - that's for Bitbucket Server, which is not the same as Bitbucket Cloud. Have a look at https://confluence.atlassian.com/bitbucket/branch-permissions-385912271.html instead; you can use that to control who can push to master or use pull requests to merge to master. To answer your…

Both the git config and the fact that it's TeamCity are irrelevant here. You need to focus on the Bitbucket credentials being used to authenticate, because that (and *only* that) will determine whether Bitbucket gets far enough into the push process for either of those other details to matter.

You need to specify the full path: ssh://git@bitbucket.org:22/yvw/odi

One or both of those should work, unless you have a firewall or something blocking those hosts or ports.

Bitbucket Cloud's ssh service is available on port 22, or you can also use altssh.bitbucket.org:443 .

Try ssh authentication.

The git:// protocol is not currently supported by either Bitbucket Server or Bitbucket Cloud. Do you have any other options for repository type?

Both Git and Mercurial treat clones as static copies, even if they're hosted on the same system. You'll need to fetch or pull to get new commits from one to the other.

It's the username. Git relies on its host operating system to handle authentication and authorization, and the commit metadata (including, but not limited to, the committer email) isn't sent until after authn/authz is complete. With that in mind, it's more efficient to have branch permissions use the Bitbucket username -…

No, your fork will not be deleted if the upstream repo is deleted. Similarly, you can delete your fork without affecting the upstream repo.

Does the source view show the source?

pages.bitbucket.io is unofficial, and *very* outdated. Your hosted page will be on the .io name; requests made to shaun_slalom.bitbucket.org will be redirected to bitbucket.org. It looks like your page is returning a 400 error, though - is it not ready to handle GET requests?

In Bitbucket Cloud, you can set this in "Branch permissions" in the repo admin panel. In Bitbucket Server, this is under "Merge checks" in either the project or repo settings.

That documentation is for Bitbucket Server, which is self-hosted. Have a look at https://confluence.atlassian.com/bitbucket/use-access-keys-294486051.html instead for Bitbucket Cloud (bitbucket.org).