Uploaded image for project: 'Bitbucket Server'
  1. Bitbucket Server
  2. BSERV-4603

Committer alias management



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


      Atlassian status as of Feb 2022

      Hi everyone,

      Thanks for your feedback, passion, and advocacy for this suggestion. Please accept our apologies for allowing this issue to remain open without a clear answer from us.

      We would love to improve committer alias management in Bitbucket Data Center. However, this use case is quite rare in an enterprise environment and is associated with high engineering costs. We made a decision that this improvement is the wrong direction for our product. We remain committed to being an open company, whether it's with regards to feature requests or bugs in our software. 

      So if we are not going to improve committer alias management, what are we doing instead? We remain committed to helping software teams deliver high-quality software faster in an increasingly competitive world. We believe that great developer tools are a key element of modern software development. To that end, we've made a lot of improvements last year and are planning to work in the following areas that help with problems development teams face now:

      • Performance and scaling to support growth
      • Security and compliance features
      • Innovations around developer productivity
      • Integrations between Atlassian and other leading products


      Anton Genkin
      Product Manager - Bitbucket Data Center & Server

      As a way more comfortable and straightforward alternative to messing around with .mailmap files, please add the "Username aliases" feature in Stash that's already existing in BitBucket.

      Implement this on a per-repository, per-project as well as system-wide level as well as for users' personal repositories. Providing buttons to move a created alias to either of the other levels could ease management of this a lot.

      This will also actually extend functionality because right now in 2.12.1, Stash apparently ignores globally configured .mailmap files – confirmed by Stash support – but only cares about .mailmap files inside repos.

      I personally think it's a very bad idea to mix up code and some configuration that has nothing to do with it, so I'd never commit a .mailmap file directly into a repository. With a mapping feature built into Stash, the configuration would be separate from the repo files. Also, even if Stash cared about globally-set .mailmap files, bigger organizations with strict permissions could also profit from this since their server admin no longer needs to fumble around with files directly on the command line every time something needs to be changed but can do it in a few clicks in the interface – or, with Stash's global/project-level permissions, even delegate that to certain other people.

      The highest priority should be on the system-level aliases, second come project-level and repository-level aliases, then personal user repositories.

      As for permissions, this scheme might be a good starting point for brainstorming the perfect solution:

      • Repository admins may add, edit and delete aliases set up for their repos
      • Project admins may add, edit and delete aliases set up for their projects and any repos in those projects
      • Stash admins may add, edit and delete aliases set up globally as well as for any project and any repo inside those
      • Moving aliases to a different level is possible whenever the user has the permissions needed to manage aliases on the target level, e.g. project admins may move a repo-level alias inside one of their repos to project-level, but repo admins may not do so.

      For personal user repositories, maybe have a toggle to switch system-level aliases on/off (in user settings, one toggle for all of the user's repos).


        Issue Links



              Unassigned Unassigned
              239cc0d4a57d Julian Rupp
              131 Vote for this issue
              88 Start watching this issue