If a user deploys their site, it captures the current state of the site source from their local machine. If they are using git to collaborate on a site and forget to pull from the remote source, they could end up deploying an out-of-date site. It would be courteous to warn the user when they are doing so, and prevent them from deploying.
We should check the status of the default remote of the current branch:
git rev-parse --abbrev-ref HEAD will get you the current branch
git config branch.<branchname>.remote will give you the default remote of the given <branchname>
git config branch.<branchname>.merge will give you the remote "ref" that is merged into the local ref
git ls-remote <remote> will list all the refs in the remote, and you want the one that corresponds to branch.<branchname>.merge
Finally, git rev-parse HEAD will get you the current commit hash of the current branch.
If the current commit hash of the current branch does not match the remote, either the remote has commits that aren't in the local, or the local has commits that aren't in the remote. To see if we have the commit, we can do git merge-base HEAD <remote commit id>. If the commit ID returned by that command is the same as <remote commit id>, then the remote commit is wholly contained in the current branch, which means we've got nothing to worry about. If nothing is returned and the exit code is non-zero, then the commit is not in our branch and we're likely out-of-date.
If we determine we are out-of-date when we run deploy (before the site is built), we should display an error and then exit. If the user then passes the -f or --force flag, we should still display an error, but then proceed with the build and deploy.
If a user deploys their site, it captures the current state of the site source from their local machine. If they are using git to collaborate on a site and forget to pull from the remote source, they could end up deploying an out-of-date site. It would be courteous to warn the user when they are doing so, and prevent them from deploying.
We should check the status of the default remote of the current branch:
git rev-parse --abbrev-ref HEADwill get you the current branchgit config branch.<branchname>.remotewill give you the default remote of the given<branchname>git config branch.<branchname>.mergewill give you the remote "ref" that is merged into the local refgit ls-remote <remote>will list all the refs in the remote, and you want the one that corresponds tobranch.<branchname>.mergegit rev-parse HEADwill get you the current commit hash of the current branch.If the current commit hash of the current branch does not match the remote, either the remote has commits that aren't in the local, or the local has commits that aren't in the remote. To see if we have the commit, we can do
git merge-base HEAD <remote commit id>. If the commit ID returned by that command is the same as<remote commit id>, then the remote commit is wholly contained in the current branch, which means we've got nothing to worry about. If nothing is returned and the exit code is non-zero, then the commit is not in our branch and we're likely out-of-date.If we determine we are out-of-date when we run
deploy(before the site is built), we should display an error and then exit. If the user then passes the-for--forceflag, we should still display an error, but then proceed with the build and deploy.