• 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.

      I am using Jira + Stash. I am able to create a new branch from a Jira issue by clicking on the "Create Branch" link. If I create the branch under a forked repo owned by myself, the new branch will not be listed in the Jira issue. Only branches in normal stash repos are listed.

        1. fork-branch.png
          fork-branch.png
          7 kB
        2. снимок375.png
          снимок375.png
          42 kB

            [BSERV-4541] branches in forked repo are not listed in the issue

            b4978340ff6b,

            As I updated 3 years ago, any branch you directly update is sent to Jira, regardless of whether it is in a fork. So if you use a fork-based workflow and you push all your work to your fork, those branches will appear in Jira. At this time we're not working on any further changes in this area, and it's not on my personal agenda to work on in my spare time either. Is there something specific you're still looking for? I'm not sure a day will ever come where all branches in all forks are listed in Jira. Personally, I don't see any significant value in listing every repository in a hierarchy simply because the branch is present. Especially for developers who use fork syncing, you end up with many branches present in your fork that you don't actually care about. Any branch you actually push to will appear in Jira, though.

            Here's a screenshot from this issue's dev panel:

            That test branch is in my personal fork of the Bitbucket Server repository. Since I pushed directly to it, it was indexed in Jira.

            Best regards,
            Bryan Turner
            Atlassian Bitbucket

            Bryan Turner (Inactive) added a comment - b4978340ff6b , As I updated 3 years ago, any branch you directly update is sent to Jira, regardless of whether it is in a fork. So if you use a fork-based workflow and you push all your work to your fork, those branches will appear in Jira. At this time we're not working on any further changes in this area, and it's not on my personal agenda to work on in my spare time either. Is there something specific you're still looking for? I'm not sure a day will ever come where all branches in all forks are listed in Jira. Personally, I don't see any significant value in listing every repository in a hierarchy simply because the branch is present. Especially for developers who use fork syncing, you end up with many branches present in your fork that you don't actually care about. Any branch you actually push to will appear in Jira, though. Here's a screenshot from this issue's dev panel: That test branch is in my personal fork of the Bitbucket Server repository. Since I pushed directly to it, it was indexed in Jira. Best regards, Bryan Turner Atlassian Bitbucket

            Boris B added a comment - - edited

            Is there any update regards?

            I.e. can I today able to see in Jira issue branches from forked repo?

            If the answer is not, then when it's suppose to be solved?

            By the way, I know that branches from forked repo in Github and Bitbucket is working.

            Boris B added a comment - - edited Is there any update regards? I.e. can I today able to see in Jira issue branches from forked repo? If the answer is not, then when it's suppose to be solved? By the way, I know that branches from forked repo in Github and Bitbucket is working.

            i_boyko,

            Unfortunately, no. The new behavior is the only behavior. Trying to make it configurable per repository would add a fair amount of complexity (for the code but also, more importantly, for administrators, who would need to configure it all, and for users, who would need to understand why their branches appear in JIRA for some repositories but not all repositories without being able to go "look" at the settings).

            Do you have a specific use case you're targeting?

            don.draper1814139281,

            I hope it's a useful improvement for many! My apologies for it taking so long to ship.

            Best regards,
            Bryan Turner
            Atlassian Bitbucket

            Bryan Turner (Inactive) added a comment - i_boyko , Unfortunately, no. The new behavior is the only behavior. Trying to make it configurable per repository would add a fair amount of complexity (for the code but also, more importantly, for administrators, who would need to configure it all, and for users, who would need to understand why their branches appear in JIRA for some repositories but not all repositories without being able to go "look" at the settings). Do you have a specific use case you're targeting? don.draper1814139281 , I hope it's a useful improvement for many! My apologies for it taking so long to ship. Best regards, Bryan Turner Atlassian Bitbucket

            Igor Boyko added a comment -

            Hi Bryan, is it possible to disable this feature for some forks or repos?
            I mean, to keep functionality as earlier when Development panel in JIRA shows main repo only
            Thank you.

            Igor Boyko added a comment - Hi Bryan, is it possible to disable this feature for some forks or repos? I mean, to keep functionality as earlier when Development panel in JIRA shows main repo only Thank you.

            Don Draper added a comment -

            @Bryan  Thanks very much for taking this on!

            Don Draper added a comment - @Bryan  Thanks very much for taking this on!

            Bitbucket Server 4.14.6 and 5.0.3 have been released with indexing for branches in forks. 5.1.0 does not include this indexing change. It will be included in 5.1.1 when that's released, and will be present in all subsequent 5.x releases.

            So, to be clear:

            • 5.0.0, 5.0.1 and 5.0.2 do not index branches in forks
            • 5.1.0 does not index branches in forks
            • 5.2.0 and all subsequent releases will index branches in forks

            Apologies for the confusing set of fix versions, but it's unavoidable when backporting fixes.

            Best regards,
            Bryan Turner
            Atlassian Bitbucket

            Bryan Turner (Inactive) added a comment - Bitbucket Server 4.14.6 and 5.0.3 have been released with indexing for branches in forks. 5.1.0 does not include this indexing change. It will be included in 5.1.1 when that's released, and will be present in all subsequent 5.x releases. So, to be clear: 5.0.0, 5.0.1 and 5.0.2 do not index branches in forks 5.1.0 does not index branches in forks 5.2.0 and all subsequent releases will index branches in forks Apologies for the confusing set of fix versions, but it's unavoidable when backporting fixes. Best regards, Bryan Turner Atlassian Bitbucket

            All,

            I've been working on solutions for this issue. It's going to be a multi-step process to truly solve it, and some of those changes are going to be bigger than others. Because this is such a critical issue for many, I've worked to break down the "ideal" solution into smaller parts, and, most relevantly for those watching this issue, focused on doing so in a way that will yield changes that are safe to backport. I don't want to gate getting access to a solution for this issue on upgrading to the new 5.x release series.

            Cutting to the chase, I've completed the first part of the overall change, which will allow Bitbutbucket Server to index branches in forks, and I've backported that change to our 4.14.x series for inclusion in 4.14.6. (Note: It will not be backported further than this. Upgrading from any previous 4.x release to 4.14 should be reasonably straightforward, especially compared to upgrading to 5.x.) 4.14.6 has not been released yet; I'll update this issue again when it is.

            This initial change indexes branches which are directly modified in all forks, personal and not. "Directly modified" includes (but is not limited to):

            • Any branch pushed to any fork
            • Any branch created from JIRA (or via the branch creation REST endpoints)
            • Branches updated by merging pull requests

            The primary activity that will not trigger branch indexing is fork syncing. Any branch that is created or updated by fork syncing will not be indexed by synchronization. This is intended to control bloat in the index, because any branch that is created or updated by fork syncing, by definition, must already exist upstream and point to the same commit. That means indexing synchronized branches is unlikely to add significant value compared to indexing fork branches where active development is being done. Additionally, because fork syncing only applies fast-forward changes, teams that use rebase-heavy workflows and fork syncing together often end up with large numbers of "dead" branches in forks, where fork syncing couldn't delete a branch when it was deleted upstream because non-fast-forward changes made the two diverge but, crucially, no actual work was done on the fork's branch. (For example, my own personal fork of the Bitbucket Server repository has over 350 such "dead" branches.) If a branch is created by fork syncing and then pushed to, or otherwise directly modified, it will be indexed at that time. Having been created or updated by fork syncing does not "blacklist" branches for indexing; it simply doesn't index them as part of synchronization.

            This indexing can't be gleaned retroactively, so upgrading to a version with this change will not magically index existing branches. However, going forward, as branches are modified in forks, those branches will be indexed.

            Best regards,
            Bryan Turner
            Atlassian Bitbucket

            Bryan Turner (Inactive) added a comment - All, I've been working on solutions for this issue. It's going to be a multi-step process to truly solve it, and some of those changes are going to be bigger than others. Because this is such a critical issue for many, I've worked to break down the "ideal" solution into smaller parts, and, most relevantly for those watching this issue, focused on doing so in a way that will yield changes that are safe to backport. I don't want to gate getting access to a solution for this issue on upgrading to the new 5.x release series. Cutting to the chase, I've completed the first part of the overall change, which will allow Bitbutbucket Server to index branches in forks, and I've backported that change to our 4.14.x series for inclusion in 4.14.6. (Note: It will not be backported further than this. Upgrading from any previous 4.x release to 4.14 should be reasonably straightforward, especially compared to upgrading to 5.x.) 4.14.6 has not been released yet; I'll update this issue again when it is. This initial change indexes branches which are directly modified in all forks, personal and not. "Directly modified" includes (but is not limited to): Any branch pushed to any fork Any branch created from JIRA (or via the branch creation REST endpoints) Branches updated by merging pull requests The primary activity that will not trigger branch indexing is fork syncing. Any branch that is created or updated by fork syncing will not be indexed by synchronization . This is intended to control bloat in the index, because any branch that is created or updated by fork syncing, by definition, must already exist upstream and point to the same commit . That means indexing synchronized branches is unlikely to add significant value compared to indexing fork branches where active development is being done. Additionally, because fork syncing only applies fast-forward changes, teams that use rebase-heavy workflows and fork syncing together often end up with large numbers of "dead" branches in forks, where fork syncing couldn't delete a branch when it was deleted upstream because non-fast-forward changes made the two diverge but, crucially, no actual work was done on the fork's branch. (For example, my own personal fork of the Bitbucket Server repository has over 350 such "dead" branches.) If a branch is created by fork syncing and then pushed to , or otherwise directly modified, it will be indexed at that time. Having been created or updated by fork syncing does not "blacklist" branches for indexing; it simply doesn't index them as part of synchronization. This indexing can't be gleaned retroactively, so upgrading to a version with this change will not magically index existing branches. However, going forward, as branches are modified in forks, those branches will be indexed. Best regards, Bryan Turner Atlassian Bitbucket

            I just stumbled on this myself after having forked our old repo for a new phase of the project, only to find that JIRA acted like all the branches of the fork didn't exist.  This lack of functionality doesn't really make sense, and I'm now going to be forced to remake the repo as a non-fork just to make JIRA work correctly.

            Jeff Reisman added a comment - I just stumbled on this myself after having forked our old repo for a new phase of the project, only to find that JIRA acted like all the branches of the fork didn't exist.  This lack of functionality doesn't really make sense, and I'm now going to be forced to remake the repo as a non-fork just to make JIRA work correctly.

            Xi Chen added a comment -

            Agree with Don. Especially the following:

            At the least, you could document this limitation in both the KB and the formal documentation.

             

            Xi Chen added a comment - Agree with Don. Especially the following: At the least, you could document this limitation in both the KB and the formal documentation.  

            Don Draper added a comment -

            It just so happens that we forked out main repository.   Engineering isn't going to be very happy when they hear about this long-standing (and disingenuously named) "suggestion".  In my world, if you clearly document that your software performs a function, even demoing it in a promotional video, and the software can't perform it, that's a "bug".  It could also be classified as "selling vaporware"; but I don't believe that applies here.  At the least, you could document this limitation in both the KB and the formal documentation.   Before I figured this out using "black box" techniques, Atlassian Support had asked me to reproduce "the problem" with debug logging and profile logging turned on in both Bitbucket and JIRA, and to provide the Support Zips.   A quick KB article would've saved me and Support more time than it would have taken to write the KB article, including editing, etc.  Heck, if you provide me with some basic guidelines, I'll write the KB article for you.  In my opinion, everybody would come out ahead if Atlassian invested more heavily in documentation and KB articles.  Giving customers the ability to submit KB articles might be helpful too, since I'm sure that I'm not the only customer who cares more about the next poor fellow user (not to mention the next Support engineer) to get nailed by this than Atlassian apparently does.

            Don Draper added a comment - It just so happens that we forked out main repository.   Engineering isn't going to be very happy when they hear about this long-standing (and disingenuously named) "suggestion".  In my world, if you clearly document that your software performs a function, even demoing it in a promotional video, and the software can't perform it, that's a "bug".  It could also be classified as "selling vaporware"; but I don't believe that applies here.  At the least, you could document this limitation in both the KB and the formal documentation.   Before I figured this out using "black box" techniques, Atlassian Support had asked me to reproduce " the problem " with debug logging and profile logging turned on in both Bitbucket and JIRA, and to provide the Support Zips.   A quick KB article would've saved me  and Support more time than it would have taken to write the KB article, including editing, etc.  Heck, if you provide me with some basic guidelines, I'll write the KB article for you.  In my opinion, everybody would come out ahead if Atlassian invested more heavily in documentation and KB articles.  Giving customers the ability to submit KB articles might be helpful too, since I'm sure that I'm not the only customer who cares more about the next poor fellow user (not to mention the next Support engineer) to get nailed by this than Atlassian apparently does.

              bturner Bryan Turner (Inactive)
              83144a36f4fa stefanhong
              Votes:
              120 Vote for this issue
              Watchers:
              100 Start watching this issue

                Created:
                Updated:
                Resolved: