File name when downloading a tag

Issue #3486 wontfix
Jérôme Berger
created an issue

When downloading a tag as a .tar.gz, .tar.bz2 or .zip archive, the file is named: "{{{user-repository-hash.}}}", same as when downloading a snapshot referred by hash. It would be nice if the archive (and the included folder) was named "{{{user-repository-tag.}}}".

For example, when downloading the file is named "{{{jmb-cseh-ad591c014a9e.tar.gz}}}" but I would prefer to get "{{{jmb-cseh-1.2.0.tar.gz}}}".

Comments (6)

  1. Erik van Zijst staff

    Hi Jérôme,

    What you're describing is how Bitbucket worked up until about a month ago, when we inadvertently changed it (and broke people's scripts that relied on that filename pattern).

    We now find ourselves in a difficult situation. Changing it back will once more break it for people en so for now we're going to stick with what we have. Should we decide to change it again in the future, we'll properly announce it.


  2. Sam Clegg

    Yes, please take the advice of Antonio Cavallo.

    Better still, do it like github does and make it so that filename can be anything you like:<username>/<repository>/get/<tag>/what_ever_you_like.tar.gz

    The contents of the file can either always be <repo>-<tag> or it can be <what_ever_you_like>.

    We rely on having sensible filenames and archive contents in the naclports project ( and this feature of github provides what we need.

    Right now, if a project uses bitbuckets tags for releasing source archives there are several drawbacks. Take for example the eigen project: Their official release source archive is There are 2 major problems with this:

    1) if you download it you end up with a file called "3.2.4.tar.gz" in your downloads directory. This is very unhelpful.

    2) if you extract this archive you see that everything is within a directory called 'eigen-eigen-10219c95fe65'. Again, not very helpful all all. This should simply be "eigen-3.2.4".

    Please please please fix this.

  3. Jorge Pablos

    Hi Guys,

    +1 to the part of the contents of the downloaded file.

    The download Zip file can easily be defined, or renamed, so that part is good for us.

    Our issue is about the content of the downloaded file once decompressed, we would expect to see our project files on the first level for automation, but instead there is a dynamically generated first level folder, which is not useful, and it prevents us from referencing files inside our structure in a consistent manner.

    For example, we would expect: -> (once decompressed ->)

    Instead, we get: (once decompressed ->)
    our-project-name-cOm1tH4sh/ (this folder is not ours, could we get the file without it inside?)

    In our case, we are trying to feed the Zip file to an AWS CodeBuild Project, and reference the 'buildspec' file inside the project in a consistent manner, like 'path/buildspec.yml', but that is not possible with the 'extra' folder without massaging the contents of the file after downloading.

    Is there a magic GET parameter by chance, to download the file without the extra level? :) e.g. ?noextrafolder=1

  4. Log in to comment