Closed jasonmueller closed 10 years ago
Makes sense, the constraint is purely the configuration validation. I can relax it further to allow any valid URL.
One thing to keep in mind is stash repositories are bare bone repositories, if you have a non-bare bone remote repository you will get an error like this:
$ git push --prune file:///Users/adriangonzalez/git/stash/test/rep_1 +refs/heads/*:refs/heads/* +refs/tags/*:refs/tags/*
Counting objects: 79, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (47/47), done.
Writing objects: 100% (79/79), 7.70 KiB | 0 bytes/s, done.
Total 79 (delta 14), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To file:///Users/adriangonzalez/git/stash/test/rep_1
* [new branch] basic_branching -> basic_branching
* [new branch] branch_mod_merge -> branch_mod_merge
* [new branch] out_of_order_branch -> out_of_order_branch
* [new tag] backdated_annotated_tag -> backdated_annotated_tag
* [new tag] retagged_signed_tag -> retagged_signed_tag
* [new tag] signed_tag -> signed_tag
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'file:///Users/adriangonzalez/git/stash/test/rep_1'
You can run $ git init --bare
to initialize your remote. However, I don't think a bare bone repository will work for the use case you describe to deploy configuration files.
The other option is to set receive.denyCurrentBranch = ignore:
$ git init
$ git config receive.denyCurrentBranch ignore
$ touch .git/hooks/post-receive
$ chmod +x .git/hooks/post-receive
$ nano .git/hooks/post-receive
And use something like the following for your post-receive hook:
#!/bin/bash
test "${PWD%/.git}" != "$PWD" && cd ..
unset GIT_DIR GIT_WORK_TREE
git reset --hard
Thank you. I'll give it a try.
The configuration doesn't currently allow using file: URLs. I'd like to use this plugin for doing continuous deployment of configuration files on push to master but won't have HTTP or SSH running on the target machines.
Is there a technical limitation to using file:, or is the http/ssh constraint only in configuration?