Repository

Creates a branch in the specified repository.

The authenticated user must have an effective REPO_WRITE permission to call this resource. If branch permissions are set up in the repository, the authenticated user must also have access to the branch name that is to be created.

Request

Responses

Deletes a branch in the specified repository.

If the branch does not exist, this operation will not raise an error. In other words after calling this resource and receiving a 204 response the branch provided in the request is guaranteed to not exist in the specified repository any more, regardless of its existence beforehand.

The optional 'endPoint' parameter of the request may contain a commit ID that the provided ref name is expected to point to. Should the ref point to a different commit ID, a 400 response will be returned with appropriate error details.

The authenticated user must have an effective REPO_WRITE permission to call this resource. If branch permissions are set up in the repository, the authenticated user must also have access to the branch name that is to be deleted.

Request

Responses

Gets the branch information associated with a single commit from a given repository.

Request

Responses

Creates a tag in the specified repository.

The authenticated user must have an effective REPO_WRITE permission to call this resource.

'LIGHTWEIGHT' and 'ANNOTATED' are the two type of tags that can be created. The 'startPoint' can either be a ref or a 'commit'.

Request

The create git tag request.

Responses

Deletes a tag in the specified repository.

The authenticated user must have an effective REPO_WRITE permission to call this resource.

Request

Responses

Request

Responses

Request

Responses

Search for restrictions using the supplied parameters.

The authenticated user must have REPO_ADMIN permission or higher to call this resource. Only authenticated users may call this resource.

Request

Responses

Allows creating multiple restrictions at once.

Request

The request containing a list of the details of the restrictions to create.

array<RestRestrictionRequest>

Responses

Returns a restriction as specified by a restriction id.

The authenticated user must have REPO_ADMIN permission or higher to call this resource. Only authenticated users may call this resource.

Request

Responses

Deletes a restriction as specified by a restriction id.

The authenticated user must have REPO_ADMIN permission or higher to call this resource. Only authenticated users may call this resource.

Request

Responses

Retrieves the synchronization status for the specified repository. In addition to listing refs which cannot be synchronized, if any, the status also provides the timestamp for the most recent synchronization and indicates whether synchronization is available and enabled. If "?at" is specified in the URL, the synchronization status for the specified ref is returned, rather than the complete repository status.

The authenticated user must have REPO_READ permission for the repository, or it must be public if the request is anonymous. Additionally, after synchronization is enabled for a repository, meaning synchronization was available at that time, permission changes and other actions can cause it to become unavailable. Even when synchronization is enabled, if it is no longer available for the repository it will not be performed.

Request

Responses

Enables or disables synchronization for the specified repository. When synchronization is enabled, branches within the repository are immediately synchronized and the status is updated with the outcome. That initial synchronization is performed before the REST request returns, allowing it to return the updated status.

The authenticated user must have REPO_ADMIN permission for the specified repository. Anonymous users cannot manage synchronization, even on public repositories. Additionally, synchronization must be available for the specified repository. Synchronization is only available if:

• The repository is a fork, since its origin is used as upstream
• The owning user still has access to the fork's origin, if the repository is a personalfork

Request

Responses

Allows developers to apply a manual operation to bring a ref back in sync with upstream when it becomes out of sync due to conflicting changes. The following actions are supported:

• MERGE: Merges in commits from the upstream ref. After applying this action, the synchronized ref will be AHEAD (as it still includes commits that do not exist upstream.
  • This action is only supported for DIVERGED refs
  • If a "commitMessage" is provided in the context, it will be used on the merge commit. Otherwise a default message is used.
• DISCARD: Throws away local changes in favour of those made upstream. This is a destructive operation where commits in the local repository are lost.
  • No context entries are supported for this action
  • If the upstream ref has been deleted, the local ref is deleted as well
  • Otherwise, the local ref is updated to reference the same commit as upstream, even if the update is not fast-forward (similar to a forced push)

The authenticated user must have REPO_WRITE permission for the specified repository. Anonymous users cannot synchronize refs, even on public repositories. Additionally, synchronization must be enabled and available for the specified repository.

Request

Responses

Retrieve a page of recently accessed repositories for the currently authenticated user.

Repositories are ordered from most recently to least recently accessed.

Only authenticated users may call this resource.

Request

Responses

Streams an archive of the repository's contents at the requested commit. If no at= commit is requested, an archive of the default branch is streamed.

The filename= query parameter may be used to specify the exact filename to include in the "Content-Disposition" header. If an explicit filename is not provided, one will be automatically generated based on what is being archived. Its format depends on the at= value:

• No at= commit: <slug>-<default-branch-name>@<commit>.<format>; e.g. example-master@43c2f8a0fe8.zip

• at=sha: <slug>-<at>.<format>; e.g. example-09bcbb00100cfbb5310fb6834a1d5ce6cac253e9.tar.gz

• at=branchOrTag: <slug>-<branchOrTag>@<commit>.<format>; e.g. example-feature@bbb225f16e1.tar

  • If the branch or tag is qualified (e.g. refs/heads/master, the short name (master) will be included in the filename
  • If the branch or tag's short name includes slashes (e.g. release/4.6), they will be converted to hyphens in the filename (release-4.5)

Archives may be requested in the following formats by adding the format= query parameter:

• zip: A zip file using standard compression (Default)
• tar: An uncompressed tarball
• tar.gz or tgz: A GZip-compressed tarball

The contents of the archive may be filtered by using the path= query parameter to specify paths to include. path= may be specified multiple times to include multiple paths.

The prefix= query parameter may be used to define a directory (or multiple directories) where the archive's contents should be placed. If the prefix does not end with /, one will be added automatically. The prefix is always treated as a directory; it is not possible to use it to prepend characters to the entries in the archive.

Archives of public repositories may be streamed by any authenticated or anonymous user. Streaming archives for non-public repositories requires an authenticated user with at least REPO_READ permission.

Request

Responses

Retrieve the attachment.

The authenticated user must have REPO_READ permission for the specified repository that is associated to the attachment.

Request

Responses

Delete an attachment.

The user must be authenticated and have REPO_ADMIN permission for the specified repository.

Request

Responses

Retrieve the attachment metadata.

The authenticated user must have REPO_READ permission for the specified repository that is associated to the attachment that has the attachment metadata.

Request

Responses

Save attachment metadata.

The authenticated user must have REPO_READ permission for the specified repository that is associated to the attachment that has the attachment metadata.

Request

The attachment metadata can be any valid JSON content

string

Responses

Delete attachment metadata.

The user must be authenticated and have REPO_ADMIN permission for the specified repository.

Request

Responses

Retrieve the branches matching the supplied filterText param.

The authenticated user must have REPO_READ permission for the specified repository to call this resource.

Request

Responses

Creates a branch using the information provided in the RestCreateBranchRequest request

The authenticated user must have REPO_WRITE permission for the context repository to call this resource.

Request

The request to create a branch containing a name, startPoint, and optionally a message

Responses

Retrieve a page of content for a file path at a specified revision.

Responses from this endpoint vary widely depending on the query parameters. The example JSON is for a request that does not use size, type, blame or noContent.

1. size will return a response like {"size":10000}
2. type will return a response like {"type":"FILE"}, where possible values are "DIRECTORY", "FILE" and "SUBMODULE"
3. blame without noContent will include blame for the lines of content returned on the page
4. blame with noContent will omit file contents and only return blame for the requested lines
5. noContent without blame is ignored and does nothing

The various parameters are "processed" in the above order. That means ?size=true&type=truewill return a size response, not a type one; the type parameter will be ignored.

The blame and noContent query parameters are handled differently from size and type. For blame and noContent, the presence of the parameter implies "true" if no value is specified; size and and type both require an explicit=true or they're treated as "false".

• ?blame is the same as ?blame=true
• ?blame&noContent is the same as ?blame=true&noContent=true
• ?size is the same as ?size=false
• ?type is the same as ?type=false

The authenticated user must have REPO_READ permission for the specified repository to call this resource.

Request

Responses

Retrieve a page of content for a file path at a specified revision.

Responses from this endpoint vary widely depending on the query parameters. The example JSON is for a request that does not use size, type, blame or noContent.

1. size will return a response like {"size":10000}
2. type will return a response like {"type":"FILE"}, where possible values are "DIRECTORY", "FILE" and "SUBMODULE"
3. blame without noContent will include blame for the lines of content returned on the page
4. blame with noContent will omit file contents and only return blame for the requested lines
5. noContent without blame is ignored and does nothing

The various parameters are "processed" in the above order. That means ?size=true&type=truewill return a size response, not a type one; the type parameter will be ignored.

The blame and noContent query parameters are handled differently from size and type. For blame and noContent, the presence of the parameter implies "true" if no value is specified; size and and type both require an explicit=true or they're treated as "false".

• ?blame is the same as ?blame=true
• ?blame&noContent is the same as ?blame=true&noContent=true
• ?size is the same as ?size=false
• ?type is the same as ?type=false

The authenticated user must have REPO_READ permission for the specified repository to call this resource.

Request

Responses

Update the content of path, on the given repository and branch.

This resource accepts PUT multipart form data, containing the file in a form-field named content.

An example curl request to update 'README.md' would be:

curl -X PUT -u username:password -F content=@README.md -F 'message=Updated using file-edit REST API' -F branch=master -F sourceCommitId=5636641a50b http://example.com/rest/api/latest/projects/PROJECT_1/repos/repo_1/browse/README.md

• branch: the branch on which the path should be modified or created
• content: the full content of the file at path
• message: the message associated with this change, to be used as the commit message. Or null if the default message should be used.
• sourceCommitId: the commit ID of the file before it was edited, used to identify if content has changed. Or null if this is a new file

The file can be updated or created on a new branch. In this case, the sourceBranch parameter should be provided to identify the starting point for the new branch and the branch parameter identifies the branch to create the new commit on.

Request

The multipart form data containing the file

Responses

Retrieve a page of changes made in a specified commit.

Note: The implementation will apply a hard cap ({@code page.max.changes}) and it is not possible to request subsequent content when that cap is exceeded.

The authenticated user must have REPO_READ permission for the specified repository to call this resource.

Request

Responses

Retrieve a page of commits from a given starting commit or "between" two commits. If no explicit commit is specified, the tip of the repository's default branch is assumed. commits may be identified by branch or tag name or by ID. A path may be supplied to restrict the returned commits to only those which affect that path.

The authenticated user must have REPO_READ permission for the specified repository to call this resource.

Request

Responses

Retrieve a single commit identified by its ID. In general, that ID is a SHA1. From 2.11, ref names like "refs/heads/master" are no longer accepted by this resource.

The authenticated user must have REPO_READ permission for the specified repository to call this resource.

Request

Responses

Retrieve a page of changes made in a specified commit.

Note: The implementation will apply a hard cap (page.max.changes) and it is not possible to request subsequent content when that cap is exceeded.

The authenticated user must have REPO_READ permission for the specified repository to call this resource.

Request

Responses

Retrieves the commit discussion comments that match the specified search criteria.

It is possible to retrieve commit discussion comments that are anchored to a range of commits by providing the sinceId that the comments anchored from.

The authenticated user must have REPO_READ permission for the repository that the commit is in to call this resource.

Request

Responses

Add a new comment.

Comments can be added in a few places by setting different attributes:

General commit comment:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
      "text": "An insightful general comment on a commit."
}

</pre>
Reply to a comment:
<pre>{
      "text": "A measured reply.",
      "parent": {
          "id": 1
      }
}
</pre>
General file comment:
<pre>{
      "text": "An insightful general comment on a file.",
      "anchor": {
          "diffType": "COMMIT",
          "fromHash": "6df3858eeb9a53a911cd17e66a9174d44ffb02cd",
          "path": "path/to/file",
          "srcPath": "path/to/file",
          "toHash": "04c7c5c931b9418ca7b66f51fe934d0bd9b2ba4b"
      }
}
</pre>
File line comment:
<pre>{
      "text": "A pithy comment on a particular line within a file.",
      "anchor": {
          "diffType": "COMMIT",
          "line": 1,
          "lineType": "CONTEXT",
          "fileType": "FROM",
          "fromHash": "6df3858eeb9a53a911cd17e66a9174d44ffb02cd",
          "path": "path/to/file",
          "srcPath": "path/to/file",
          "toHash": "04c7c5c931b9418ca7b66f51fe934d0bd9b2ba4b"
      }
}

Note: general file comments are an experimental feature and may change in the near future!

For file and line comments, 'path' refers to the path of the file to which the comment should be applied and 'srcPath' refers to the path the that file used to have (only required for copies and moves). Also, fromHash and toHash refer to the sinceId / untilId (respectively) used to produce the diff on which the comment was added. Finally diffType refers to the type of diff the comment was added on.

For line comments, 'line' refers to the line in the diff that the comment should apply to. 'lineType' refers to the type of diff hunk, which can be:- 'ADDED' - for an added line;- 'REMOVED' - for a removed line; or- 'CONTEXT' - for a line that was unmodified but is in the vicinity of the diff.'fileType' refers to the file of the diff to which the anchor should be attached - which is of relevance when displaying the diff in a side-by-side way. Currently the supported values are:- 'FROM' - the source file of the diff- 'TO' - the destination file of the diffIf the current user is not a participant the user is added as one and updated to watch the commit.

The authenticated user must have REPO_READ permission for the repository that the commit is in to call this resource.

Request

the comment

Responses