Reputation: 178
HI guys I am a newbie to git but we are trying to use it in the office for tracking changes to large web projects.
We have the website files for a large site set on a shared network drive, here is my current process and the problems I am facing!
I am on Windows 10 and using the git command line interface.
I cd to this website directory on our shared drive and do the following:
$ cd /x/Clients/ClientA/Website/
$ git init
$ git status
$ git add --all
$ git commit -m "Initial Commit"
I then cd to my desktop and clone a local version:
$ cd /c/Users/Account/Desktop/
$ git clone /x/Clients/ClientA/Website/
This clones perfectly, I now change a file using Atom inside my Desktop/Website/ folder and save it.
I then commit those changes and try to push them back to my shared drive:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")
$ git add --all
$ git commit -m "Edited file"
[master 76782c6] Edited file
1 file changed, 3 insertions(+)
$ git push
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (11/11), 922 bytes | 0 bytes/s, done.
Total 11 (delta 6), reused 0 (delta 0)
remote: Checking connectivity: 11, done.
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: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
remote:
remote: You can set the 'receive.denyCurrentBranch' configuration variable
remote: to 'ignore' or 'warn' in the remote repository to allow pushing into
remote: its current branch; however, this is not recommended unless you
remote: arranged to update its work tree to match what you pushed in some
remote: other way.
remote:
remote: To squelch this message and still keep the default behaviour, set
remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To X:/Clients/ClientA/Website/
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'X:/Clients/ClientA/Website/'
Can anyone point me in the right direction on how I can get it set up so that multiple people in the office can clone and push to that one place on the network drive successfully?
Thanks!
Upvotes: 0
Views: 2724
Reputation: 124704
It's not a common practice to a non-bare repository, and as the error message tells, this is not enabled by default. I recommend to use a bare repository instead, without a working tree.
You can create a bare repository from the existing /x/Clients/ClientA/Website/
like this:
git clone /x/Clients/ClientA/Website --bare /x/Clients/ClientA/Website.git
After this, you can clone from /x/Clients/ClientA/Website.git
and you can push to it.
It cannot have a working tree though.
If, for example, you want to have a working tree always up to date with master
,
you could create a dedicated clone for that from /x/Clients/ClientA/Website.git
, and you could setup a post-commit hook in /x/Clients/ClientA/Website.git
to trigger git pull
in the dedicated clone.
Upvotes: 5
Reputation: 30267
You are trying to push on a remote that has a "working tree" and right now, on that repo, the branch that is checked out is the one you are trying to push into. Think of it the other way around: You are working on branch X and someone else tries to push into your branch X. You would like git to restrict it because it would be like pulling a rug from under your feet, right? Well, that's it.
Upvotes: 1