deploy Prompt when local ref does not match remote ref

Say you're on master locally, if you deploy -e production it's possible that it's going to deploy an older version because someone has pushed remote master after you last pulled. You need to always git pull if you're not providing the ref, to make sure that you're deploying the correct version.

Apr 24 '15 23:04 sanjayprabhu

Hmm, this actually shouldn't be a problem, right? If you're on master, then it's going to create the deployment using the master ref and get resolved on GitHub, which will resolve it to the current HEAD on GitHub.

But it's still a good point, it's not really clear what sha is actually being deployed when the ref is resolved using git.

Apr 25 '15 02:04 ejholmes

Does it use the master ref? It deployed the local SHA to staging for me (to staging). Let me see if I can reproduce it.

Apr 27 '15 01:04 sanjayprabhu

Yeah, it'll use the master ref if you're using v0.0.2.

Apr 27 '15 16:04 ejholmes

Ah, I was on v0.0.1.

But yeah, would be nice to see the sha and provide a warning if it doesn't match the local sha.

Apr 27 '15 18:04 sanjayprabhu

Yeah, that would be nice. It's pretty easy right now to push a commit, then deploy before the new HEAD actually registers on github.

Could probably use the GET /repos/:owner/:repo/git/refs/:ref endpoint to resolve the branch to a sha and check that it matches HEAD

Apr 27 '15 20:04 ejholmes

I'll give it a shot when I have some time.

Apr 27 '15 20:04 sanjayprabhu

This is still an issue actually. If I have repo1@develop checked out locally and run deploy -e production repo2 it'll attempt to deploy repo2@develop which is not what i expect (i'd expect it to default to master).

Sep 29 '15 19:09 bmarini

Ah yeah, that's definitely a legit bug. If you specify a repo on the command line, we shouldn't fallback to git.

Sep 29 '15 19:09 ejholmes