# GIT & Symbolic Links 4 messages from 2012-03-12 to 2012-03-17. Participants: Sassy Natan, Kevin, Enrico Weigelt, Andrew Sayers. Thread: https://gitlist.dev/t/29925 ## Sassy Natan, 2012-03-12 16:44 Subject: GIT & Symbolic Links Message-ID: URL: https://gitlist.dev/e/CACHQFzEJATc2hiSdAgoGg3vssQ-CShF%2B89TOkzVwaf_ujYy%2B3w%40mail.gmail.com In-Reply-To: ``` Hi Group, I'm consider myself as a new baby when it come to GiT. But I have just migrate my users from SVN to GIT and I have some questions in mind I want to share with you. Is it possible to do the following: Say I have a really big GiT repo (something around 1GB) name DEV. In the SVN days, each of my developers (100 Users) had to clone a local copy of the DEV Repo in his home folder, so total of 100GB was used in my shared storage (NFS Drive) where something around 85% was actually just a copy of the same files. When I used the De-Duplication function (Under ZFS File System) I could easy see how the volume is shrinking, but I more inserting in different kind of solution, now when it comes to GIT. So for the example let's consider that user A clone the DEV GIT Repo into his/her home folder (/home/A/DEV) User B want to clone the same Repo. But now, I don't want user B to clone the all tree and files, but instead to have a symbolic links to the /home/A/DEV folder. All files and directories in the /home/B/DEV will be a links to the /home/A/DEV. Once user B actually want to change a file, ?somehow? the git brake the link, and have a local copy of that specific file. When the file is push back the link become back. While trying to get some feedback in the IRC roon, some users point me to git-annex and unionfs. Both project seems to be cool, git-annex really have nice options, but I don't see how this going to help me. Regarding unionfs - well I'm still not sure. Maybe someone can help here... Thanks ``` ## Kevin, 2012-03-13 10:06 Subject: Re: GIT & Symbolic Links Message-ID: URL: https://gitlist.dev/e/CAO54GHDgvoHdF3x8%2BkZwJ2XfB9Tyk1_xwrbfKux-b6wxS9koGw%40mail.gmail.com In-Reply-To: ``` As the IRC channel already concluded, git itself has no option to 'break' symbolic links on write, as git is not the only one editing these files, but your editor does too. This is why this is never going to work without the support of your editor, or with something more low level, like file system support On Mon, Mar 12, 2012 at 5:44 PM, Sassy Natan wrote: > Hi Group, > > I'm consider myself as a new baby when it come to GiT. > But I have just migrate my users from SVN to GIT and I have some > questions in mind I want to share with you. > > Is it possible to do the following: > > Say I have a really big GiT repo (something around 1GB) name DEV. > In the SVN days, each of my developers (100 Users) had to clone a > local copy of the DEV Repo in his home folder, so total of 100GB was > used in my shared storage (NFS Drive) where something around 85% was > actually just a copy of the same files. > > When I used the De-Duplication function (Under ZFS File System) I > could easy see how the volume is shrinking, but I more inserting in > different kind of solution, now when it comes to GIT. > > So for the example let's consider that user A clone the DEV GIT Repo > into his/her home folder (/home/A/DEV) > User B want to clone the same Repo. But now, I don't want user B to > clone the all tree and files, but instead to have a symbolic links to > the /home/A/DEV folder. > All files and directories in the /home/B/DEV will be a links to the /home/A/DEV. > > Once user B actually want to change a file, ?somehow? the git brake > the link, and have a local copy of that specific file. > When the file is push back the link become back. > > While trying to get some feedback in the IRC roon, some users point me > to git-annex and unionfs. > Both project seems to be cool, git-annex really have nice options, but > I don't see how this going to help me. > > Regarding unionfs - well I'm still not sure. > > Maybe someone can help here... > > Thanks > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at  http://vger.kernel.org/majordomo-info.html ``` ## Enrico Weigelt, 2012-03-17 16:00 Subject: Re: GIT & Symbolic Links Message-ID: <20120317160015.GB18712@mailgate.onlinehome-server.info> URL: https://gitlist.dev/e/20120317160015.GB18712%40mailgate.onlinehome-server.info In-Reply-To: ``` * Sassy Natan wrote: Hi, > So for the example let's consider that user A clone the DEV GIT Repo > into his/her home folder (/home/A/DEV) > User B want to clone the same Repo. But now, I don't want user B to > clone the all tree and files, but instead to have a symbolic links to > the /home/A/DEV folder. > All files and directories in the /home/B/DEV will be a links to the /home/A/DEV. Symlinks wont fit here, as the userland sees them as links (and treats them as such). What you're looking for is some solution that does the cow stuff hidden from the normal userland. Perhaps via unionfs or something fuse-based. BUT: I'd first raise the question if your tree needs to be that big at all. Perhaps it should be splitted into several smaller ones. What actually does your tree make that big ? cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- ``` ## Andrew Sayers, 2012-03-17 17:05 Subject: Re: GIT & Symbolic Links Message-ID: <4F64C448.5040108@pileofstuff.org> URL: https://gitlist.dev/e/4F64C448.5040108%40pileofstuff.org In-Reply-To: ``` Not really an answer to your question, but `git-relink` will de-duplicate the contents of your .git directory using hardlinks. Your actual files will remain as big as ever, but the (potentially much larger) git storage for older versions will take considerably less disk space. - Andrew ```