Re: Large media in git (was: How it was at GitTogether'08)?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 10 November 2008 10:30:53 Jakub Narebski wrote:
> On Sun, 9 Nov 2008, Kai Blin wrote:
> > On Sunday 09 November 2008 17:31:47 Jakub Narebski wrote:
> > > The workaround is to put all large files for example in 'media/'
> > > folder, and make this folder be submodule. Each clone of repository can
> > > have this 'media' submodule either present (both in object database,
> > > although usually separate from main project object database), or not
> > > present (not cloned and not checked out).
> >
> > Tim was talking about that media/ folder and managing that in git. If you
> > want to work on the media, you might end up getting hundreds of gigabytes
> > of data to get that folder, even if you only need to change one single
> > file.
> >
> > That's the issue we're running into, and I don't thing submodules solve
> > this at all.
>
> Ah, well... Submodules cannot be workaround for _this_ issue. You can
> have only all or nothing: either all files in media/ or none of them,
> both in working directory like in repository object database... well
> unless you subdivide further.
>
> I guess that mentioned work on the media is in remote setting (you
> cannot have main repository on network drive) so Dana How's proposed
> solution would not work for you, is it?

If my google-fu worked, the proposed solution you're talking about involves 
simply hiding large blobs from pack files, right? In that case it won't work, 
as the users of the repository indeed are remote.

Cheers,
Kai

-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developer        http://wiki.winehq.org/KaiBlin
Samba team member     http://www.samba.org/samba/team/
--
Will code for cotton.

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux