Issue #589 open

File history should follow copies and renames (BB-681)

created an issue

It would be nice if the file history showed the history across copies, e.g. log -f.

Otherwise it's difficult to track the full history of a file that has been renamed. It doesn't show up in the source file list, so you must know that the file was renamed, and look at the source before its "first" revision.

Comments (126)

  1. Maxime Henrion

    I find this very annoying as well; not just for the file history, but also for the "annotate" command which becomes entirely useless when the file has been renamed.

  2. Rob Vesse

    I would really like to see this happen, I have a large project where I've recently made some large re-organisations to make it more maintainable going forward. However the lack of this feature makes revision history for files essentially useless to people browsing via the web interface

  3. Ville Saalo

    This would be an important feature. Here's one sample file in a Mercurial repository for testing this issue: Click the revision link and then the "Full Commit" button to see how one file was deleted and another one was added. If I now click the "view file" button at the deleted file, I only get an error message about a dead link, i.e. there's no way for me to access the history of the file. Surely that's not the optimal way of handling things. At command line "hg log --follow src/com/saibotd/bitbeaker/activities/" still shows all the history for the file that was moved.

  4. agaricusb

    This feature is crucial for many of my projects - I've basically renamed every file in the repository, rendering the BitBucket per-file commit history log not very useful. Sure I can view the full history from the command-line, but having it easily browsable on BitBucket would be very useful.

    The problem occurs with git repositories as well (git-log needs the "--follow" parameter); unfortunately, GitHub also lacks this feature :(. Hope this feature can be added to BitBucket. Thank you.

  5. muv

    +1 For Git I use extra options (--follow, -M30%, -C30%) to do a deeper search for renames and copies locally. Adding --summary also shows actual similarity index between revisions of a moved file. Would be nice to have some of these in Web UI. Or at least give a hint to the user that he can find more with local clone.

  6. Boris Ceranic

    Bump. Really important feature. In past several months, I've rearranged my entire repository upside-down twice. File history was useless even after the first set of renames.

  7. Drew Wilson

    One Solution to this, If you use the command 'hg serve' and then navigate to 'localhost:8000', you CAN see the files history even with moves in place.

  8. Miguel Vitorino

    That is not a solution, it's a work around. There are obvious solutions to get this working locally. The intention of the bug is to get a solution on

  9. Eli Bishop [Atlassian]

    Atlassian engineer here, desperately pleading for this feature - we frequently need to refer to old changelogs since we support multiple old versions of our products, and after renaming a source directory this becomes a huge pain.

  10. Daniel Lemos

    Any plan to implement this? Without this feature the file history show moved files were just created on the commit that moved them to the new name/location.

  11. Martin Geisler

    Would everybody who has added a "+1" comment on this issues please go and vote on it instead? That way you avoid notifying everybody who follow the issues with an email saying nothing more than "+1".

  12. jeffjlins

    Is there another company/product like bitbucket that does show history? Might be worth switching... this seems pretty basic and atlassian does not appear to be motivated to fix bugs given that it's been FIVE years.

  13. 71days

    It would really be nice to have this fixed, even after five years... Projects are bound to have files moved/renamed and this can render the web source code diff useless sometimes. Bitbucket is a great tool, having such frustrating issues solved would make it even greater!

  14. Sebastien Gandon

    We are migrating from svn to git, and we use this opportunity to refactor completely our code base by moving all the project into nice clean named subfolders. What was my surprise when I could not access to any history on any of the files on bitbucket (it appears to be the same in GitHub and I suppose that would be a great differentiator).

  15. Ember Quill


    I would think that tracking file history through renames (something that Git DOES support) would be a given. This issue is five years old. If you're not going to do anything about it, just close it already.

  16. Alastair Paragas

    Would be a helpful feature!

    I added my parent directory to my Git repository, and the rename operations were successful. Git history for files can be tracked with --follow flag after the rename, but the Bitbucket interface shows it as if the file was created without any previous history.

    There is no fix for this at the moment, right? We just have to stick with it until this feature is produced?

  17. Edward Abrams

    @joshuagolub: I think the issue here (if memory serves, it has been a while) is that particularly when reviewing pull requests, which are a bitbucket and not a git feature, this UI goes completely nuts when you move files, showing massive changes and potentially hundreds of thousands of changed lines. Granted git works fine, but again, if I am remembering correctly, the request here is to make PRs work better, at least in part.

  18. Oleg Oshmyan

    Normal history viewing should certainly follow moves as well. At the end of the day, you can do everything using command-line Git and Mercurial, but since Bitbucket provides a UI, that UI should be useful.

  19. Ember Quill

    This issue is actually the main reason why I moved from BitBucket to GitLab last June and never looked back. I had to do a major refactoring of a repository to prep it for a merge with another repository, which involved moving and renaming a large number of files.

    Whether it's "quite a bit of work" or not, It's one of the oldest open feature requests on the tracker. You'd think that six years would be enough time to at least come up with a plan to implement this at some point in the future, but apparently not. The fact that it took five years to even acknowledge the issue and tell us that they have no plans to address it doesn't exactly fill me with confidence.

  20. Dmitriy Kuminov

    Please implement that! It's ridiculous to not follow the file moves in History and DO so in Blame. Makes no sense. A big obstacle in daily work. Github has it, GitLab has it. I will have to move away if you don't.

  21. Tom Goossens

    Thank you for your message.

    I am out of the office until 13APR2015. I am following up on email, however there may be delays. For urgent matters, feel free to contact me on +32496844019.


    Tom Goossens

  22. Dmitriy Kuminov

    Too bad guys that you are out of the office. Besides using it privately, I was also thinking about moving our company's repositories to Bitbucket (and pay you some money) but this feature is surely a deal breaker.

  23. Daniel MacDonald

    Well guys? I just asked my team to clean up the high level directory structure of our main project and now I learn we effectively lose the ability to navigate ALL OF OUR HISTORY if they go through with it. I am contemplating moving our company to github absent any kind of timeline or commitment to usability here. We are paying customers btw.

  24. Chris P

    I suffered a lot of grief trying to figure out why I lost my history. Then realized I have it at command line but not through the bitbucket interface. This should be a SIMPLE change by bitbucket. All the information is right there via a log --follow. How has this been requested for 5+ years and never implemented?

  25. Sebastian Garde

    It's quite sad actually. Just turn this issue collector off completely if you have no intention at all to listen to your customers nor want to dignify them with an answer every couple of years or so. I cannot believe that implementing the basics of this can be so difficult.

  26. bean5

    I think they haven't implemented it because they figure those who would request would be people who know how to use git to do exist for this, so it wouldn't be novel to their product. That is just my guess as to why things like this stay undone.

  27. Luke Meyers

    Sure, but that's a rather thin excuse for releasing otherwise worthwhile tools that don't work properly because obvious features are missing. Features aren't independent; UX is gestalt.

  28. bean5

    Luke Meyers I might agree. But it doesn't matter what I think. I'm just making assumptions as to what Atlassian is is just about all we can do since they remain fairly silent on this issue.

  29. OskarGP

    So guys when this will be available, it is extremly hard to follow changes when more that couple of files were moved to different package (and this is very common thing in business application development today) You see that a package has a name that doesn't correspond to its content anymore. You immediately fix it using automated refactoring. Then if you have some other changes you make the code review very difficoult.

  30. Mario Pérez


    This issue was opened at 2009, lot of issues marked as duplicated, staff accepting it should be fixed, people leaving bitbucket and migrating to other servers for this reason... I can't believe..

  31. bean5

    IMO I think it is time to file a bug with Atlassian explaining that it appears that long-standing issues seem to have less weight than others--and receive no official updates, which causes confusion and frustration. Lack of speedy customer service is a bug in my book.

  32. Mario Pérez

    At the moment of writing this, this is the 7th issue with more votes, and there are only 15 issues older.. (there are 1985 open issues). As paying customer, I opened an other issue. They said they have an internal issue and are working in it but no ETA can be provided... Some feedback from the team would be much appreciated (in case of any team member read this of course).

  33. Log in to comment