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.
