Warning: templates not found /Users/lars/share/git-core/templates # TEST RUN A - Default Git 2.9 ( ab7797d) and Git LFS 1.2.1 NO_GETTEXT=YesPlease NEEDS_SSL_WITH_CRYPTO=YesPlease make -j 8 CFLAGS="-I/usr/local/opt/openssl/include" LDFLAGS="-L/usr/local/opt/openssl/lib" Set -x git lfs clone repo cd repo git checkout removed-files time git checkout master time git checkout removed-files I executed both test runs on a 2,5 GHz Intel Core i7 with SSD and OS X.Ī test run is the consecutive execution of four Git commands:Ģ.
Gitkraken switch branch fails files deleted Patch#
If the Git community agrees that this kind of approach would beĪcceptable then I will start to work on a proper patch series with cross Please note that this implementation is just a quick and dirty proof ofĬoncept. I implemented these "cache hits" natively in Git. LFS objects are already available in the cache (e.g. Even on the Git mailing list a user reported that issue. That invokes the clean/smudge filter (e.g. Unfortunately that fix helps only with cloning. On Windows) even if the Git LFS executable only accesses its local cache.īased on my previous findings Steve Streeting ( improved theĬlone times of Git LFS repositories with a lot of files by a factor of 10 The process invocation of these filters requires noticeable time (especially Git LFS is an application that is executed via Git clean/smudge filter. Git hosting services support it (GitHub, Atlassian Bitbucket , The project gained quite some momentum as almost all major Git LFS is an extension to Git that handles large files for Git I am lookingįor comments if my approach would be acceptable by the Git community. Repositories with a large number of Git LFS files. I found a way to make Git LFS faster up to a factor of 100x in Maybe it gets Do you see an issue with disabling the filter in the clone statement temporarily? Here are the clone timings for the test repo mentioned above (exact test run commands below): Test/time in secĪs you can see the "no smudge filter" solution is more than 50 times faster than the GIT_LFS_SKIP_SMUDGE flag on my I will try to create a git-core patch which allows to deactivate a git config value on git clone (e.g.
I also tested the true command (test B2) is to measure the overhead of calling an external process. See this gist for a git clone wrapper using this approach. The best I came up with was to set the LFS filter to the cat command (test B1). Unfortunately I was not able to run git clone with a deactivated config. The problem with this approach is that LFS is deactivated globally and that might cause trouble with parallel Git/Git-LFS processes. Ideally we would deactivate the LFS filter on the initial clone all together which I tried with test C. The git-lfs binary is ~10MB and it takes quite some time to run it even if it does nothing due to the GIT_LFS_SKIP_SMUDGE flag (test A). However, disabling the smudge filter with a variable is still slow. Of course the daemon should be optional.ĭo you think this idea is worth exploring? Do you see an easier way to tackle this I know. However, what if we could convince the Git core team to merge a patch that (optionally) makes Git talking to a local socket instead of executing a process for Git filters? Then we could run a Git-LFS daemon kind of thing and I imagine the checkout and other operations could be much faster. As far as I understand the design of Git-LFS there is not much we can do about it. 10k files means 10k process executions which is, of course, horribly slow on Windows. The reason for this slow checkout is, as you probably already know, the invocation of the Git-LFS process via the Git attribute filters.
Gitkraken switch branch fails files deleted mac#
consider this repo with 15k LFS files:Ĭheckout time on my Mac with SSD is around 10min (which is OK).Ĭheckout time on Windows with SSD is well over an hour (which is not so nice). We started using Git-LFS for all binary files and experienced very slow checkouts for a repository with +10k binaries.Į.g.
We are using Git-LFS at my company and in general we are really happy as it nicely solves the binary files problem in Git.
0 kommentar(er)
