We couldn't load all Actvitity tabs. Refresh the page to try again.
If the problem persists, contact your Jira admin.
IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-3469

Pull request references in the Git repository are never removed after merge or decline

    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      When a user opens a pull request, some references are created inside the Git repository hosted in the Stash server. These references live in files stored in <STASH_HOME>\data\repositories\<REPO_ID>\refs\pull-requests\<PULL_REQUEST_ID>

      This is great and allows one to, for example, configure the build server to build pull requests and the result of the merge.

      However, these references are never deleted from the Git repository, so there's no way for a build server to know when to stop monitoring these references. Because of that, if you merged 1000 pull requests in the past, the build server will show you 1000 build results, one for each pull request, even though you already merged (or declined) these 1000 pull requests and are not interested in these build results anymore.

      I would expect the reference to be removed after the pull-request has been merged or declined. If a user reopens it, then the reference should be recreated.

      Thanks,
      Caio Proiete

            Loading...
            IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
            Uploaded image for project: 'Bitbucket Data Center'
            1. Bitbucket Data Center
            2. BSERV-3469

            Pull request references in the Git repository are never removed after merge or decline

              • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

                When a user opens a pull request, some references are created inside the Git repository hosted in the Stash server. These references live in files stored in <STASH_HOME>\data\repositories\<REPO_ID>\refs\pull-requests\<PULL_REQUEST_ID>

                This is great and allows one to, for example, configure the build server to build pull requests and the result of the merge.

                However, these references are never deleted from the Git repository, so there's no way for a build server to know when to stop monitoring these references. Because of that, if you merged 1000 pull requests in the past, the build server will show you 1000 build results, one for each pull request, even though you already merged (or declined) these 1000 pull requests and are not interested in these build results anymore.

                I would expect the reference to be removed after the pull-request has been merged or declined. If a user reopens it, then the reference should be recreated.

                Thanks,
                Caio Proiete

                        Unassigned Unassigned
                        ab4ae5e3f28f augustoproiete
                        Votes:
                        7 Vote for this issue
                        Watchers:
                        8 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                            Unassigned Unassigned
                            ab4ae5e3f28f augustoproiete
                            Votes:
                            7 Vote for this issue
                            Watchers:
                            8 Start watching this issue

                              Created:
                              Updated:
                              Resolved: