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

Committer alias management



    • UIS:
    • Feedback Policy:
      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 December 2016

      Hi everyone,

      Thanks to everyone for voting and commenting on this suggestion. Your input in the comments helps us understand how this affects you and what you're hoping to accomplish with Bitbucket Server.

      We spend a significant amount of time on an ongoing basis to determine our product investments in Bitbucket Server. Unfortunately, we are not currently planning to address this suggestion in the next 12 months. In the last 12 months, we've resolved 10 of the top 30 feature requests, and our upcoming roadmap includes a number of other top voted suggestions, including in-browser editing, improvements to search functionality, better JIRA integration, and providing an even better code review experience.

      I understand that this may be disappointing, but we believe it’s important for us to be open, honest and transparent with our customers. Product feedback is collected from a number of different sources and is evaluated when planning the product roadmap. You can learn more about our process here.

      Norman Ma

      Product Manager - Bitbucket 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
              mail67 Julian Rupp
              129 Vote for this issue
              88 Start watching this issue