On Tue, Apr 14, 2020 at 10:15:22PM -0700, SJW wrote: [...] > In my replicated version, I created a brand new empty subdomain then > configured git to push to live [git push live master] and it worked > perfectly - my entire website got pushed up and was working perfectly based > on my tests. [...] > On the live site, there are a few directories and files which are NOT part > of the repo (/backup, /wp, etc.) > Will this cause problems? The live server will have extra files and folders > that aren't in the repo - is this going to make the live server return > errors (e.g. out of sync) or will it try and add them? Or can I just push > and we're golden? [...]
Sorry for a somewhat glib answer but why not actually test that with an another dedicated deployment which is not production but is otherwise organized exactly as that? I mean, should someone have given a definitively-sounding answer asserting there will be no problems, would you seriously just go ahead with that assertion without checking? That's a sure path to faluire. As to the problem at hand, _if_ you're talking about the so-called "push-to-deploy" feature introduced in Git 2.3 [1], when enabled the server does two things after receiving your data: 1. Verified the work tree (where the files are checked out, that is, the place from where your files get served by the web server) is clean. Being clean means having no changes in the tracked files. Tracked files are those present in the commit which was checked out last (that is, which the HEAD points at). 2. Performs an action equivalent to running git reset --hard THE_TIP_OF_THE_HISTORY_JUST_PUSHED to that the HEAD is updated accordingly and the affected tracked files are updated, when needed. A possible catch there is about the tracked files. If you do not have any files in these /backup, /wp etc hierarchies tracked in the tip commit of what you push-to-deploy, Git has to turn blind eye to those directories. It will not ever try to remove any files in them unless such a file was tracked. An example: 1. You have for some reason added and committed a filed /wp/foo/bar.php and then pushed-to-deploy that commit. Git will create the indicated file in the remote work tree (unless it already exists, of course). 2. You remove that file locally, commit and push-to-deploy this commit. Now Git will attempt to remove that file - as Git knows the file was tracked and now was removed. In other words, should you not mess with the "special" directories in the commits you make, you should be golden. But let me repeat: do not blindly rely on random advice; test! 1. https://github.blog/2015-02-06-git-2-3-has-been-released/#when-shouldnt-you-use-push-to-deploy -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20200417113131.wanhvnuv6je35ixw%40carbon.