On 24 Sep 2015, at 22:44, Luke Diamand <l...@diamand.org> wrote: > On 23 September 2015 at 12:42, Lars Schneider <larsxschnei...@gmail.com> > wrote: >> >> On 23 Sep 2015, at 13:25, Luke Diamand <l...@diamand.org> wrote: >> >>> Adding back git@vger.kernel.org, which I inadvertently dropped off the >>> thread. >>> >>> On 23 September 2015 at 12:22, Luke Diamand <l...@diamand.org> wrote: >>>> On 23 September 2015 at 11:09, Lars Schneider <larsxschnei...@gmail.com> >>>> wrote: >>>>> >>>>> On 23 Sep 2015, at 11:22, Luke Diamand <l...@diamand.org> wrote: >>>>> >>>>>> On 23 September 2015 at 09:50, Lars Schneider <larsxschnei...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> On 23 Sep 2015, at 10:18, Lars Schneider <larsxschnei...@gmail.com> >>>>>>> wrote: >>>>>> >>>>>> <snip> >>>>>> >>>>>>> >>>>>>> I think I found an easy fix. Can you try it? >>>>>>> >>>>>>> (in case my mail app messes something up: I changed line 2240 in >>>>>>> git-p4.py to 'self.cloneDestination = os.getcwd()’) >>>>>> >>>>>> It fixes the problem, but in re-running the tests, I'm seeing t9808 >>>>>> fail which doesn't happen on next. >>>>> Confirmed. I fixed it. >>>>> Do you think it makes sense to create a new roll v8 for Junio? >>>> >>>> How about we leave it a day or two in case anything else crawls out of >>>> the woodwork? >>>> >>>> Thanks! >>>> Luke >> sounds good to me! > > OK, not sure if I'm just doing something daft here....but it seems to > be ignoring the size limit! > > I've got the version from the branch: > > 8fee565 git-p4: add Git LFS backend for large file system > > Plus the couple of oneliner fixes for cloneDestination. > > I've created a repo with a file called foo, size 16MB, and another > file called foo.mp4, which is just a symlink to foo. > > I then do: > > $ mkdir a > $ cd a > $ git init . > $ git config git-p4.largeFileSystem GitLFS > $ git config git-p4.largeFileExtensions mp4 > $ git config git-p4.largeFileThreshold 100k > $ git-p4.py sync -v //depot > > That reports that both foo and foo.mp4 have been pushed into LFS: > > //depot/foo --> foo (16 MB) > Reading pipe: ['git', 'config', '--bool', 'git-p4.pushLargeFiles'] > foo moved to large file system > (/home/lgd/git/git/x/git/a/.git/lfs/objects/08/0a/080acf35a507ac9849cfcba47dc2ad83e01b75663a516279c8b9d243b719643e) > //depot/foo.mp4 --> foo.mp4 (0 MB) > foo.mp4 moved to large file system > (/home/lgd/git/git/x/git/a/.git/lfs/objects/2c/26/2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae) > > But the file system says otherwise: > > $ ls -l > -rw-r--r-- 1 lgd lgd 16777216 Sep 24 21:38 foo > -rw-r--r-- 1 lgd lgd 3 Sep 24 21:38 foo.mp4 > > As does git: > > git ls-files --debug > .gitattributes > ctime: 1443127106:535552029 > mtime: 1443127106:535552029 > dev: 65025 ino: 13638459 > uid: 1000 gid: 1000 > size: 94 flags: 0 > foo > ctime: 1443127106:579552030 > mtime: 1443127106:579552030 > dev: 65025 ino: 13638462 > uid: 1000 gid: 1000 > size: 16777216 flags: 0 <<<<<<<<<<<<< Quite large! > foo.mp4 > ctime: 1443127106:599552030 > mtime: 1443127106:599552030 > dev: 65025 ino: 13638463 > uid: 1000 gid: 1000 > size: 3 flags: 0 > > What's going on? I believe this is correct. Git-LFS uses the clean/smudge filter to replace the LFS pointer with the actual file on checkout. Therefore you see the actual file! You can find details here: https://github.com/github/git-lfs/blob/master/docs/spec.md#intercepting-git
Can you run `du -hs .git/objects` in your Git repository? This should report a value well below 16 MB. Cheers, Lars -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
