Re: [PATCH v7 0/7] git-p4: add support for large file systems

[Lars Schneider <larsxschneider@gmail.com>]

On 24 Sep 2015, at 22:44, Luke Diamand <luke@diamand.org> wrote:

> On 23 September 2015 at 12:42, Lars Schneider <larsxschneider@gmail.com> wrote:
>> 
>> On 23 Sep 2015, at 13:25, Luke Diamand <luke@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 <luke@diamand.org> wrote:
>>>> On 23 September 2015 at 11:09, Lars Schneider <larsxschneider@gmail.com> wrote:
>>>>> 
>>>>> On 23 Sep 2015, at 11:22, Luke Diamand <luke@diamand.org> wrote:
>>>>> 
>>>>>> On 23 September 2015 at 09:50, Lars Schneider <larsxschneider@gmail.com> wrote:
>>>>>>> 
>>>>>>> On 23 Sep 2015, at 10:18, Lars Schneider <larsxschneider@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