{"thread":{"id":"17816","subject":"Cloning into an existing directory","startedAt":"2009-02-16T07:10:45Z","lastAt":"2009-02-17T02:53:17Z","messageCount":5,"participants":["Brent Goodrick","Russell Steicke","Andrew Ruder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"104908","messageId":"e38bce640902152310x195a14e5p445817bdfc6e319f@mail.gmail.com","threadId":"17816","inReplyTo":null,"subject":"Cloning into an existing directory","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-16T07:10:45Z","receivedAt":"2009-02-16T07:10:45Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"Hi,\n\nI would like to manage my startup scripts such as .bashrc and other\nsetup files relative to my HOME directory using Git. However,\ngit-clone disallows cloning into the existing \".\" directory, but only\nallows cloning into a subdirectory that does not yet exist.  If my\nhome directory is /home/brentg and my remote repository is on\nremote_machine:~brentg/my_setup.git then git clone in my home\ndirectory on the local machine creates /home/brentg/my_setup with\nfiles such as .bashrc inside it, which is not what I want. I want them\nchecked out and managed _in_ the current working directory, and not to\nmess with other files or directories that already exist that are never\nto be managed by git.\n\nI don't want to create softlinks from files in the HOME directory down\ninto the subdirectory (e.g., /home/brentg/.bashrc -->\nmy_setup/.bashrc) if I can at all avoid it, since then to do so for\nall of my setup would require extra scripting work, and it may be the\ncase that some setup files are required to be regular files and not\nsymbolic links by certain programs.  Moving the files manually is also\nout of the question, since then I can't do a git diff operation on the\nfile directly.\n\nI did see the --bare option to clone, but the entry in the git-clone\nman page implies that using that option turns off a lot of tracking of\nthings that I believe I will need:\n\n       --bare\n           Make a bare GIT repository. That is, instead of creating\n<directory> and placing the administrative files in\n           <directory>/.git, make the <directory> itself the $GIT_DIR.\nThis obviously implies the -n because there is nowhere to check\n           out the working tree. Also the branch heads at the remote\nare copied directly to corresponding local branch heads, without\n           mapping them to refs/remotes/origin/. When this option is\nused, neither remote-tracking branches nor the related\n           configuration variables are created.\n\nSpecifically, the statement: \"branch heads at the remote are copied\ndirectly to corresponding local branch heads, without mapping them to\nrefs/remotes/origin\" and \"neither remote-tracking branches nor the\nrelated configuration variables are created\" are what is scaring me\noff.\n\nIs there a way do to this, or is the --bare option really what I need\nhere? If so, what are the caveats of the use of that option given the\nabove \"scary\" statements.\n\nWhat is interesting to note, is that git clone on a local repository\nto \".\" seems to work just fine. It is only when cloning from remote\nrepositories that it complains about the target being an existing\ndirectory.\n\nThanks,\nbg\n"},{"id":"104909","messageId":"c1b8b6670902152331p9bbdb8fo7bf7048039b5301c@mail.gmail.com","threadId":"17816","inReplyTo":"e38bce640902152310x195a14e5p445817bdfc6e319f@mail.gmail.com","subject":"Re: Cloning into an existing directory","fromName":"Russell Steicke","fromEmail":"russellsteicke@gmail.com","sentAt":"2009-02-16T07:31:55Z","receivedAt":"2009-02-16T07:31:55Z","isPatch":false,"sender":{"key":"russellsteicke@gmail.com","avatar":null},"body":"On 2/16/09, Brent Goodrick <bgoodr@gmail.com> wrote:\n> Hi,\n>\n>  I would like to manage my startup scripts such as .bashrc and other\n>  setup files relative to my HOME directory using Git. However,\n>  git-clone disallows cloning into the existing \".\" directory, but only\n>  allows cloning into a subdirectory that does not yet exist.  If my\n>  home directory is /home/brentg and my remote repository is on\n>  remote_machine:~brentg/my_setup.git then git clone in my home\n>  directory on the local machine creates /home/brentg/my_setup with\n>  files such as .bashrc inside it, which is not what I want. I want them\n>  checked out and managed _in_ the current working directory, and not to\n>  mess with other files or directories that already exist that are never\n>  to be managed by git.\n\ncd\ngit init\ngit remote add origin remote_machine:~brentg/my_setup.git\ngit fetch\ngit branch master origin/master\ngit checkout master\n\nYou may have to delete .bashrc and others before git will overwrite\nthem on checkout.\n\n\n\n-- \nVirus found in this message.\n"},{"id":"104964","messageId":"e38bce640902160813u2771d55co3eb583a0922c09c5@mail.gmail.com","threadId":"17816","inReplyTo":"c1b8b6670902152331p9bbdb8fo7bf7048039b5301c@mail.gmail.com","subject":"Re: Cloning into an existing directory","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-16T16:13:12Z","receivedAt":"2009-02-16T16:13:12Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"Thanks very much for the advice, Russell.\n\nI did a test by creating the small repo with one file in it, .bashrc\nand got to the point of the git-fetch. That git-fetch did not complain\nabout the pre-existing .bashrc file. Should it, or is the design of\ngit-fetch to alter the state inside the .git area only and not the\nworking tree?  The scan of the user manual and the git-fetch man page\ndoes not seem to clarify the effect (none?) that git-fetch has on the\nworking tree.\n\nNow, I see that you said it would complain upon checkout, which it did:\n\n$ git checkout master\nerror: Untracked working tree file '.bashrc' would be overwritten by merge.\n\nFair enough: git is doing the right thing here and not overwriting the\ntarget file since it is not yet git-controlled.   Given that I may\nhave many files, my naive way of fixing that is to\n\n1. Move aside each file it complains about\n2. Run the git-checkout command again\n3. Move each file back to their original names, thus creating a local\nedit w.r.t. git\n4. Run git diff to see those changes, making additional edits\n5. Finally, check in the result\n\nTo side-step writing my own wrapper script around git, is there a\ncommand-line option to do steps 1 through 3, but not 4 and 5?\n\nThanks again for your help,\nbg\n\n\nOn Sun, Feb 15, 2009 at 11:31 PM, Russell Steicke\n<russellsteicke@gmail.com> wrote:\n> On 2/16/09, Brent Goodrick <bgoodr@gmail.com> wrote:\n>> Hi,\n>>\n>>  I would like to manage my startup scripts such as .bashrc and other\n>>  setup files relative to my HOME directory using Git. However,\n>>  git-clone disallows cloning into the existing \".\" directory, but only\n>>  allows cloning into a subdirectory that does not yet exist.  If my\n>>  home directory is /home/brentg and my remote repository is on\n>>  remote_machine:~brentg/my_setup.git then git clone in my home\n>>  directory on the local machine creates /home/brentg/my_setup with\n>>  files such as .bashrc inside it, which is not what I want. I want them\n>>  checked out and managed _in_ the current working directory, and not to\n>>  mess with other files or directories that already exist that are never\n>>  to be managed by git.\n>\n> cd\n> git init\n> git remote add origin remote_machine:~brentg/my_setup.git\n> git fetch\n> git branch master origin/master\n> git checkout master\n>\n> You may have to delete .bashrc and others before git will overwrite\n> them on checkout.\n>\n>\n>\n> --\n> Virus found in this message.\n>\n"},{"id":"104974","messageId":"a030d93b0902160848x1c0521c3jb5ed2f1bf865a097@mail.gmail.com","threadId":"17816","inReplyTo":"e38bce640902160813u2771d55co3eb583a0922c09c5@mail.gmail.com","subject":"Re: Cloning into an existing directory","fromName":"Andrew Ruder","fromEmail":"andy@aeruder.net","sentAt":"2009-02-16T16:48:08Z","receivedAt":"2009-02-16T16:48:08Z","isPatch":false,"sender":{"key":"andy@aeruder.net","avatar":"https://gravatar.com/avatar/cd5239f6d3c9acac61e817de7f7d497e518415e23720f170a10e0663a7981963?d=mp&s=160"},"body":"On Mon, Feb 16, 2009 at 9:13 AM, Brent Goodrick <bgoodr@gmail.com> wrote:\n> 1. Move aside each file it complains about\n> 2. Run the git-checkout command again\n> 3. Move each file back to their original names, thus creating a local\n> edit w.r.t. git\n\nActually, on my git (1.6.0.4) this just magically works due to the\nfact that 'git init' sets up the repository with HEAD pointing to\nrefs/heads/master (which doesn't exist yet) and you go ahead and\ncreate the master branch with the 'git branch' command.\n\nIn other words, in this particular situation the 'git checkout'\ncommand is completely unnecessary and if you just run a 'git status'\nyou should already see that git sees all the differences already as\nlocal edits (assuming you didn't call you branch in the 'git branch'\nstep something other than master).\n\n-- \nAndrew Ruder <andy@aeruder.net>\nhttp://www.aeruder.net\n"},{"id":"105065","messageId":"e38bce640902161853s20d44f5bmde42713ab66963df@mail.gmail.com","threadId":"17816","inReplyTo":"a030d93b0902160848x1c0521c3jb5ed2f1bf865a097@mail.gmail.com","subject":"Re: Cloning into an existing directory","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-17T02:53:17Z","receivedAt":"2009-02-17T02:53:17Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"On Mon, Feb 16, 2009 at 8:48 AM, Andrew Ruder <andy@aeruder.net> wrote:\n>\n> On Mon, Feb 16, 2009 at 9:13 AM, Brent Goodrick <bgoodr@gmail.com> wrote:\n> > 1. Move aside each file it complains about\n> > 2. Run the git-checkout command again\n> > 3. Move each file back to their original names, thus creating a local\n> > edit w.r.t. git\n>\n> Actually, on my git (1.6.0.4) this just magically works due to the\n> fact that 'git init' sets up the repository with HEAD pointing to\n> refs/heads/master (which doesn't exist yet) and you go ahead and\n> create the master branch with the 'git branch' command.\n>\n> In other words, in this particular situation the 'git checkout'\n> command is completely unnecessary and if you just run a 'git status'\n> you should already see that git sees all the differences already as\n> local edits (assuming you didn't call you branch in the 'git branch'\n> step something other than master).\n\nWell, it does show them as local edits, and actually shows the file as\ndeleted. I ended up having to do a git-add on those files and commit\nthem, which will work for me.\n\nbg\n"}]}