Why I hate git

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.

The Conversation {12 comments}

  1. glandium {Sunday August 7, 2011 @ 10:57 am}

    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.

  2. Tyler Breisacher {Sunday August 7, 2011 @ 11:40 am}

    What would make that error message clearer? It seems quite understandable to me.

  3. Anonymous {Sunday August 7, 2011 @ 12:54 pm}

    What behavior would you prefer in this situation, exactly? The error message seems to provide a pretty clear explanation of the problem.

  4. Axel Hecht {Sunday August 7, 2011 @ 2:35 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.

  5. Chris Double {Sunday August 7, 2011 @ 4:07 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.”

  6. hop {Sunday August 7, 2011 @ 4:28 pm}

    and then again you used push -f which is sort of bad behavior since its going to erase history

  7. glandium {Sunday August 7, 2011 @ 10:59 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.

  8. pd {Monday August 8, 2011 @ 3:16 am}

    Git could prompt the user to push to a new branch, couldn’t it?

  9. Neil Rashbrook {Monday August 8, 2011 @ 4:12 am}

    Why is git asymmetrical, i.e. why isn’t pulling from one end the same as pushing from the other?

  10. Tobu {Monday August 8, 2011 @ 5:02 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.

  11. Tobu {Tuesday 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, 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.

  12. Tobu {Tuesday August 9, 2011 @ 5:38 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.

Sorry, comments for this entry are closed at this time.