{"thread":{"id":"39933","subject":"Can we get a git clone flag to override the \"required empty directory\" behaviour?","startedAt":"2015-07-24T18:04:27Z","lastAt":"2015-07-24T21:41:28Z","messageCount":2,"participants":["Mike Kasprzak","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"266734","messageId":"CACjsLYAPqCujmR0wQM-CD=qrPJz1zrC11Pe=C07DUBdEsG2r7A@mail.gmail.com","threadId":"39933","inReplyTo":null,"subject":"Can we get a git clone flag to override the \"required empty directory\" behaviour?","fromName":"Mike Kasprzak","fromEmail":"mike@sykhronics.com","sentAt":"2015-07-24T18:04:27Z","receivedAt":"2015-07-24T18:04:27Z","isPatch":false,"sender":{"key":"mike@sykhronics.com","avatar":null},"body":"Hi,\n\nI run a project with 2 repositories. One is a vagrant based toolchain\n(a VM that runs a LAMP server), and the other is the source code.\nBecause I want my users to keep and make their changes to a clone of\nthe source repository, we can't use submodules. They make their\nchanges, test locally, and push them at me when they're done.\n\nThe source code goes in a 'www' subdirectory, but for an improved user\nexperience, I include a pre-configured version of the config file in\nthat 'www' directory. That way, after they check out the code and\nstart their local server, it just works. Easy.\n\nWhat I would like to do is git clone inside that directory. Alas, git\nwill not let you clone in any directory containing a file.\n\nToday we use `the workaround`, which involves doing a git init, adding\na remote origin, fetching, and finally checking it out.\n\nhttp://stackoverflow.com/a/18999726\n\nThis is `fine`, but it's not a good user experience. All we really\nwant is a clone, and there just happens to be a configuration file\npre-installed in the same directory.\n\nCan we please get a flag (say -f or --force) for git clone that\noverrides the default behavior of not allowing you to clone in to a\nnon-empty directory. If there already was a .git directory in that\ndirectory, sure that's a no-go scenario. An with a name like --force,\nit should be aggressive, overwriting anything it sees. Again, git can\nalready do this, it's just a lot more long winded that it should be.\n\nThanks,\n\nMike Kasprzak\n"},{"id":"266761","messageId":"xmqq6159kzcn.fsf@gitster.dls.corp.google.com","threadId":"39933","inReplyTo":"CACjsLYAPqCujmR0wQM-CD=qrPJz1zrC11Pe=C07DUBdEsG2r7A@mail.gmail.com","subject":"Re: Can we get a git clone flag to override the \"required empty directory\" behaviour?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-07-24T21:41:28Z","receivedAt":"2015-07-24T21:41:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Kasprzak <mike@sykhronics.com> writes:\n\n> What I would like to do is git clone inside that directory. Alas, git\n> will not let you clone in any directory containing a file.\n\nIn the ideal world, I think both of these two commands:\n\n    $ git clone $URL somewhere\n    $ cd somewhere && git clone $URL .\n\nshould behave just like:\n\n    - if somewhere/.git exists, barf and fail\n    - otherwise, do the \"git init && git add remote && git fetch\"\n      followed by \"git checkout\" dance.\n\nwithout any additional option.  The final \"checkout\" step should\nfail if the \"untracked files\" you have in the existing directory\ninterfere with it.\n\nIt used to be that you always had to create a \"new\" directory, not\neven an empty directory was allowed.  Recently we took a small step\nin that direction.\n\nThat hasn't happened, and will not happen unless somebody works on\nit.  The thing is that it would not just be the matter of adding a\ncommand line flag.  There are tons of things \"git clone\" can do\ndifferently from \"git fetch\" and using much simpler and performant\nlogic because it assumes that the directory it is cloning into is an\nempty one.\n"}]}