When I tried 'git push origin master' to remote repository on my external disk, git warning occured stating that pusing to checkout repository will in next releases of git refused by default. On external disk I have checkouted project and I want to send changes that I did on my computer to these reposiotry. Is 'git push origin master' not the right way? Do I have to 'git pull ...' on repository on my external disk? So I cannot push changes but just pull them? Only working with 'bare' repository is different? So if repository on my external disk was a bare repository I could push changes to it? Do I understand correcly?
2 Answers
Read the warning carefully. The new default prohibition is only on pushing to the currently checked out branch in a non-bare repository. It is perfectly OK to push to any other branch in a non-bare repository.
The reason for this is that the push process has no direct access to the working tree so the index and branch head get changed under the working tree. When you subsequently go to the working tree it looks like working tree has undone the changes pushed mixed in with any changes that were genuinely in development. This makes it very difficult to separate the two sets of changes.
Pushing to other branches has no such downsides. You can then go to that repository and merge those changes into the checked out branch if desired.

- 755,051
- 104
- 632
- 656
-
4I didn't understand this answer until I read [git ready » push to only bare repositories](http://gitready.com/advanced/2009/02/01/push-to-only-bare-repositories.html) and [all about "bare" repos -- what, why, and how to fix a non-bare push](http://sitaramc.github.com/concepts/bare.html) (especially the "yeah yeah, but why do I need a bare repo?" section). Now, however, I do! – Alexander Wallin May 03 '11 at 15:26
-
Do we have ability to push in not checked out branch and then using post-receive hook merge origin barnch with branch was updated? – Nikita U. Apr 02 '13 at 13:25
You shouldn't push to a non-bare repository because pushing will only update the internal state of the repo, and won't affect the checked-out, on-disk copies of the files. Thus, you could run into problems if you start doing work in that repo without first updating (via git checkout
) the on-disk copies of the state of the files in the repo.

- 398,885
- 90
- 523
- 479
-
-
3becomingGuru: Correct; a push is effectively the opposite of a fetch. Pull = fetch + merge into current branch. – ebneter Jan 27 '10 at 19:14
-
2The key is that a pull also updates the files in the working tree (the "on-disk" files), which neither a push nor a fetch does. – mipadi Jan 27 '10 at 19:34