This is excellent news !!! We were waiting for this. We will have to evaluate this new version before upgrading.

Yes, crystal. Thank you very much!!!

jonathan.reyes

Bitbucket Server is the 4.x rebrand of Stash. No version of the product called "Stash" will ever have Git LFS. However, if you upgrade your Stash instance (major versions 1, 2 or 3) to Bitbucket Server 4.3, you'll get LFS support.

Does that help clarify?

Best regards,
Bryan Turner
Atlassian Bitbucket

This is great news! How about in Stash? Do we have an ETA?

Git Large File Storage (LFS) support has shipped in Bitbucket Server 4.3: https://confluence.atlassian.com/display/BitbucketServer/Bitbucket+Server+4.3+release+notes

We are also waiting for this very important feature. We hope to start evaluating it soon. I'll try to illustrate why this feature could bring us major improvements to our development speed.

We started migrating from SVN to Bitbucket (Stash) and Bamboo in June 2014, and have started implementing "Gate Keepers". In our current environment, we use Pull Request in Bitbucket combined with binary files being managed in SVN. SVN is our legacy system we are migrating from, but all our binary files are still managed in SVN while our source code has been migrated into Bitbucket for the most part.

These 2 independant systems (Bitbucket and SVN) make it hard to get full benifits from "Gate Keeper" Plan Branches (where auto-merging is done only when our Bamboo build is green). The SVN commits are already done by the time the "Gate Keeper" decides to reject the "Pull Request" because of a RED build.

With the independance between "Pull Requests" in Bitbucket on one side and SVN commits on the other side, our Bamboo builds are often RED. Broken builds of our low level "Configuration Items" at the bottom of our "Configuration Items" hierarchy build dependencies is very costly. Our build times have been greatly reduced for our "incremental watchdog builds", but our "full official builds where all the various levels of automated testing are performed" are still very long. A low level "Configuration Item" red build, even when fixed immediately, means that our highest level builds in the dependency chain will only be available the next day to our QA teams. That is very costly and frustrating to our agile development teams.

I'm glad to hear Atlassian is expecting to be done in less than a year. This JIRA issue is the most important feature we are waiting for. Atlassian tools (Confluence, JIRA, Bitbucket and Bamboo) are well integrated and are providing great value to us so far. Keep up the good work.

While we wait for this feature (which is quite critical for us as well). Is it possible to manually integrate git-lfs with Bitbucket server and then replace it with your work?

Can you at least give a rough estimate on when it will be implemented and available?
Is it more like 1 month or 1 year?
We're about to make a decision on which system we'll get to manage large binary files and it would be great to know.

We are actively working on it.

Any news on this? Is there any ETA for supporting Git LFS?

Here's the description from the duplicate issue (BSERV-7300) I created awhile back that better describes the various perks of Git LFS for the convenience of all those not in the know, as the description on this issue is rather vague.

An open source Git extension for versioning large files

Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise.

Features

By design, every git repository contains every version of every file. But for some types of projects, this is not reasonable or even practical. Multiple revisions of a large file take up space quickly, slowing down repository operations and making fetches unwieldy.

Git LFS overcomes this limitation by storing the metadata for large files in Git and syncing the file contents to a configurable Git LFS server. Some of the key features include:

• Tight integration with Git means you don't have to change your workflow after the initial configuration.
• Large files are synced separately to a configurable Git LFS server over HTTPS, so you are not limited in where you push your Git repository.
• Large files are only synced from the server when they are checked out, so your local repository doesn't carry the weight of every version of every file when it is not needed.
• The meta data stored in Git is extensible for future use. It currently includes a hash of the contents of the file, and the file size so clients can display a progress bar while downloading or opt out of a large download.
• Clients and servers can make use of all the features of HTTPS, such as caching content locally on a CDN, resumable uploads and downloads, or performing requests in parallel for faster transfers.

More Info: https://git-lfs.github.com/
Source Code: https://github.com/github/git-lfs

You can read all about Atlassian's involvement in helping make all this happen in collaboration with GitHub here | https://developer.atlassian.com/blog/2015/10/contributing-to-git-lfs/

P.S. I'm surprised Atlassian hasn't brought this up sooner on here and on their various blogs :/

UPDATE: It appears that Atlassian is providing both Bitbucket Cloud & Server updates here: https://bitbucket.org/site/master/issues/11204/support-git-lfs-extension-bb-12743

v1.0 of Git-LFS has been released - https://github.com/github/git-lfs/releases

Hi all,

Just to recapture my update from earlier, although plans are subject to change this feature is a priority for the development team and is on our roadmap, however we're not able to provide a timeline for when it will be resolved at this stage. You can learn more about the process here.

Since I figured joerg.herzinger would repost his comment from STASH-7300 here but it seems he still hasn't, I'll be doing it for him so that more people are informed of his work thus far on a Stash Git LFS Implementation

I've started some work on this topic. There is still a lot to do, but basically it is already fully working: https://github.com/joerg/stash-git-lfs
Any help is appreciated. Just send me a pull request, write an email or file a bug.

Source: https://jira.atlassian.com/browse/STASH-7300?focusedCommentId=762780&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-762780

@vitalyk: Nope, no free Artifactory support for this feature

@David Vega: AFAIK Git LFS Support for Artifactory should also work with non-commercial license (see also http://www.jfrog.com/confluence/display/RTF/Git+LFS+Repositories )...although built-in support in Stash would surely still be beneficial.

Enterprise Git LFS solutions are starting to appear: http://www.jfrog.com/article/git-lfs-repositories/

Such a solution is almost $3,000 which is not within my budget, so it would be tremendous added value to Stash.

At higher enterprise grade solutions, it would be almost $30k of reasons to go with Stash.

I should also mention that you can find the BitBucket counterpart for this request here: https://bitbucket.org/site/master/issue/11204/support-git-lfs-extension

EDIT: Opps I was meant to post that on STASH-7300 (using mobile phone to post on a desktop website = bad idea)

Thanks Benjamin, I've updated the issue.

Have you considered git-fat as an alternative to git-annex? If so, could you or should I create a separate issue ticket for it?

*Source: https://github.com/cyaninc/git-fat

p.s. first time seeing a issue's resolution marked as "Timed out" is this issue dead or is it under internal review before making a decision on whether to reopen the issue or not?

Speaking for our customer (transitioning from several gitolite servers):

• as a developer I need to store and version big development builds
• as a configuration manager I need to store and version third party RPMs
• as a system administrator I would like to support this functionality in one server - e.g. Stash without need for special remotes.

From my understanding there is just need to support selected commands from git-annex-shell, at the visual side there no special requirements - no diffs or visualisation.

Please reopen with more information regarding the use case and how you envision the annex support to work.

Hey cyoshioka, how do you envision that "support". Stash acting as a special remote for git-annex?

Did this come from a customer or support case?