> Now every developer at HashiCorp knows that you `git clone` any project in the company, and `vagrant push` to deploy. It doesn't matter how it works under the covers.
We already have a standard for that. It's called "make" to build, and "make deploy" to deploy. Put a Makefile next to your Vagrantfile like you should have done in the first place. :)
Sure :), but that's yet-another-thing you need to manage. You could put all that logic in a Vagrantfile. It's about reducing the number of touch points.
I definitely see your side of the argument, and we certainly have Makefiles in our projects too. Vagrant Push provides a way for an organization or team to choose what is best for them and lower the barrier to entry for developers on a project.
"OOH man, we have all these tools that no one understands anymore! I know, let's make a tool to abstract this away!"
git hooks are another option, as are shell aliases, SCM integration, CI/CD systems, etc. This seems like yet-another-layer-of-abstraction to cover for bad / misunderstood / underutilized abstractions under it.
We already have a standard for that. It's called "make" to build, and "make deploy" to deploy. Put a Makefile next to your Vagrantfile like you should have done in the first place. :)