{"thread":{"id":"25139","subject":"symlink impact: parent dir of working tree is a symlink","startedAt":"2010-09-18T01:11:30Z","lastAt":"2010-09-18T01:11:30Z","messageCount":1,"participants":["Neal Kreitzinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"150924","messageId":"i713k3$nco$1@dough.gmane.org","threadId":"25139","inReplyTo":null,"subject":"symlink impact: parent dir of working tree is a symlink","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2010-09-18T01:11:30Z","receivedAt":"2010-09-18T01:11:30Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"      What is the impact if the parent directory of a git repo is a symlink?\n\n      In the git release notes I've noticed a trend of symlinks not playing \nwell with git.  I don't normally use symlinks, but my impression is that the \ngit release notes were referring to the scenario when a subset of files in \nyour working tree are symlinks.  I have a symlink scenario I now have to \ndeal with and I'm not sure what impact it will have on my git results.  Here \nis the scenario:\n\n      *At this time, all of our git repos reside on the root partition of a \nsingle linux server.\n      *We have two systems under development and they have separate \n\"development environments\":\n      (a)One dev environment uses the linux command line to maneuver the \nfile system and to run their git commands.\n      (b)The other dev environment uses an in-house developed menu system \nthat is text-based using bash scripts to run the git commands.  The users \nare not supposed to run any git commands from command line in this dev \nenvironment (This was not my decision so please don't hold it against me.)\n      *System (a) gets periodically merged into (b) by rebasing (a) onto \n(b).  (a) is the legacy system and (b) is the future system.  (a) resides \nunder /home/user/ where there are several users, and (b) resides under \n/opt/xyz/\n      *We have a goldbox (baremetal linux server) that contains several git \nrepos and they are all full copy clones made with the file:/// url.  The \ngoldbox is a \"powerful\" box.\n      *We have a betabox (baremetal linux server) that is for testing risky \nprocedures before implementing them on the goldbox.  The betabox is a \n\"weaker\" box.\n      *I need to bring the betabox up-to-date with the goldbox, but the \ndevelopment environment on the root partition of the goldbox is too big to \nfit on the root partition of the betabox.  Therefore, we have symlinked the \n/opt/xyz/ and /home/ directories to the /u/ partition (which resides on the \nsame hard-disk as the root partition) which has plenty of space to hold the \ndevelopment environment.\n      *As a result, the scripts that point to /opt/xyz/ and /home/user/ to \nfind the git repos on the root partition of the goldbox will still work on \nthe betabox, but on the betabox these paths are symlinked to /u/ partition.\n      */opt/xyz/ and /home/ are the only symlinks.  There are no symlinks in \nthe working trees or .git directories or git template directories.  None of \nthe \"external\" git files, e.g. gitconfig, .gitconfig, or template files are \nsymlinks.\n      *Is this betabox setup still valid for a beta test for the goldbox? \nHas this symlink setup that I've introduced on the betabox introduced  a \ndifference that could cause git to produce different results?  If I have \nintroduced a such a difference, how much impact do you think it will have? \nHow valid do you think the results on such a betabox would be for proving \ntheir safety on the goldbox?\n\n      If this betabox setup with symlinks is a valid beta test for the \ngoldbox, this would save us from having to rebuild the betabox with a larger \nroot partition.  Thanks!\n\n      v/r,\n      Neal\n"}]}