wokbok:django-durationRel axelhecht$ git push -f Counting objects: 7, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 560 bytes, done. Total 4 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (4/4), 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: 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 /Users/axelhecht/src/django-durationRel ! [remote rejected] master -> master (branch is currently checked out) error: failed to push some refs to '/Users/axelhecht/src/django-durationRel'
Also known as ux-jargon and completely useless.
All you need to read is the first line:
“refusing to update checked out branch: refs/heads/master”
You’re pushing to a repository that has a corresponding working copy, which is checked out from the branch you’re pushing to. And git doesn’t want you to do that. Either use a bare repository (one that doesn’t have a working copy), or push to a different branch.
Comment by glandium — August 7, 2011 @ 10:57 am
What would make that error message clearer? It seems quite understandable to me.
Comment by Tyler Breisacher — August 7, 2011 @ 11:40 am
What behavior would you prefer in this situation, exactly? The error message seems to provide a pretty clear explanation of the problem.
Comment by Anonymous — August 7, 2011 @ 12:54 pm
The obviously right behaviour for a DVCS for pushing from one local repo to another local repo would be to just push.
The solution to achieve what I wanted was to cd to that repo and pull.
Which isn’t even remotely advertised.
Again, it should just push. But maybe that’d require it to give at least some value to the DAG.
Comment by Axel Hecht — August 7, 2011 @ 2:35 pm
It doesn’t “just push” for the reasons outlined in the error message: “because it will make the index and work tree inconsistent with what you pushed, and will require ‘git reset –hard’ to match the work tree to HEAD.”
Comment by Chris Double — August 7, 2011 @ 4:07 pm
and then again you used push -f which is sort of bad behavior since its going to erase history
Comment by hop — August 7, 2011 @ 4:28 pm
> Again, it should just push. But maybe that’d require it to give at least some value to the DAG.
For one, push can’t merge. And it can’t update the working copy (and really shouldn’t) if you push to the currently checked-out branch.
Comment by glandium — August 7, 2011 @ 10:59 pm
Git could prompt the user to push to a new branch, couldn’t it?
Comment by pd — August 8, 2011 @ 3:16 am
Why is git asymmetrical, i.e. why isn’t pulling from one end the same as pushing from the other?
Comment by Neil Rashbrook — August 8, 2011 @ 4:12 am
You may be more comfortable with a git wrapper that adds some extra tutorial-style documentation, like eg: http://people.gnome.org/~newren/eg/
Here, eg makes the correct guess and asks you to use pull instead. It also formats the message better, without wasting so much space prefixing every line. If this guess is reliable enough you could suggest it for git.git.
Comment by Tobu — August 8, 2011 @ 5:02 am
@Neil: The configuration on one side can be completely different from the one on the other. Branch names, preferred transports, repository packing options, hooks will be very different between a hosting site and the average developer repository. Git will not guess at how the remote side is configured, and is perfectly correct to ask you to run the command yourself.
Comment by Tobu — August 9, 2011 @ 5:37 am
@Neil: The configuration on one side can be completely different from the one on the other. Branch names, preferred transports, repository packing options, and hooks will be very different between a hosting site and the average developer repository.
Git will not guess at how the remote side is configured, and is perfectly correct to ask you to run the command yourself.
Comment by Tobu — August 9, 2011 @ 5:38 am