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 (8)

  1. Erik van Zijst

    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. Grégory Le Vaguerèse

    Is it possible to avoid creating the root directory called "project-repository-10219c95fe65" in the downloadable archives ?

    I would like to directly have the contents of my repository in the downloaded archive.

  5. PipingRock Development

    Hi Gregory,

    We had the same request, hoping there was a GET parameter we could pass to the archive URLs, etc. so the inner-dynamic directory was not created, Bitbucket support replied it was not possible through regular 'Archive' downloads.

    They suggested to use "git archive" from console instead, to download zipped versions of a particular commit, etc., which worked perfectly for us, caveat: it only works connecting with SSH credentials (not HTTPS).

    I hope this helps,

  6. Log in to comment