BOFH answer: RTFM

But I'm trying to get over that tendency, so I will point you to a
good on-line manual for git. You really need to understand the basics.
Try reading here:

Now, to address your stated problem, I will try to explain the problem
and how to correct it. But I sometimes don't make too much sense. So
please bear with me if I sometimes seem to be "talking down". I'm just
trying to not leave anything out.

The first thing you need to realize is that there are _two_ types of
git repositories. There is the one on your local machine. This is
normally in a directory called ".git" in your "working directory".
This .git directory contains the entire git repository, old versions
of the files and history, in a compressed form. And the names are
really weird looking. There is also what is called a "bare
repository". This is the type of directory to which you normally do a
"git push". You normally put a local project under git by creating the
"working directory" for the project and then doing a "git init"
command when you have done a "cd" into the "working directory". This
sets up the ".git" subdirectory and some control files. Now, for the
"bare repository", which is what you need to properly do a "git push",
you go to the directory into which you want the new bare repository
and issue a command like: git init --bare myProject.git  . This
creates a new subdirectory called "myProject.git" which contains only
repository files. That is, you won't see files that have names like
they are in your "working directory". Also, this directory is normally
on a "server" which is accessible to every PC which will be accessing
the "myProject". This could just be some reserved directory on your
PC, but that is unlikely. This may be on an NFS (or Windows) share
which is accessible to a lot of PCs on a LAN. Or it may be accessible
via the Internet.

As an example, I have a directory on an NAS (Network Attached Storage)
box called /SmartStor1/Volume1/PUBLIC/git in which I keep my bare
repositories. This is where I keep the repositories for my "shared"
work. I work on some things both at home and at work. This NAS box is
accessible via the Internet. The NAS box is on a LAN in my house. It
is NFS mounted to a Linux box. When I want to start a new "shared"
project, I set it up at home with a command like:

git init --bare /SmartStor1/Volume1/PUBLIC/git/newProject.git

Then, on the same PC (at home remember), I issue the command:

cd ~/projects
git  clone file:///SmartStor1/Volume1/PUBLIC/git/newProject.git

This creates a new subdirectory under ~/projects called "newProject"
(note that the ".git" is not on the end). This sets up my working
directory to have the ".git" subdirectory with its control files, and
point to the bare repository on my NAS box. I can now create files in
~/projects/newProject and lower directories for my new project. As you
do, I can then do "git add -A ." to add my new & changed files to the
git INDEX. I then do a "git commit" to stage them into the local
repository (remember it's in the .git subdirectory). And, lastly, I
can do a "git push" or "git push --all" to send my changes into the
bare repository at /SmartStor1/Volume1/PUBLIC/git/newProject.git

The above is all being done on my home LAN, so there no real problem
with access. But, for work, I need to be able to get to my "server"
via the Internet to access that NAS box. I have this set up by using
DYNDNS to register my home IP address. And I run SSH server software
on my main, home, Linux box. So at work, I can "clone" my bare
repository using commands similar to:

cd ~/projects
git clone ssh://myHouse/SmartStor1/Volume1/PUBLIC/git/newProject.git

Now I can do the same at work as I do at home. Just edit files,
eventually do a "git add -A ." followed by a "git commit" followed by
a "git push"

But I will warn you that if you do this sort of thing, before you do
any editing or any thing else, first do a "git pull" to get any
updates made to the bare repository. So my usual method at home or
work is to do:

cd ~/projects/newProject
git pull # get any updates I've made from the other system
... do my edits, compiles, whatever
git push #send any changes back to the bare repository

If you don't bracket your work with the "git pull' ... "git push",
some day you are likely to end up with a "merge conflict" and that can
get bothersome to sort out. What will tip you off is when you try to
do the "git push" and it fails because the bare repository has changes
not in your local directory. You must _then_ do the "git pull" to get
the updates. But this "git pull" _might_ result in a merge conflict
which you must resolve before you can successfully do the "git push".
It's easier to develop the "git pull" ... "git push" habit. It only
takes a couple of seconds and can save some grief in the future.

I do hope this does make sense and is helpful.

On Thu, Mar 12, 2015 at 6:51 PM, William Lasiewicz <> wrote:
> By the way,  this is what I get
> C:\GITtest>git push --all
> Counting objects: 29, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (24/24), done.
> Writing objects: 100% (29/29), 25.24 KiB | 12.00 KiB/s, done.
> Total 29 (delta 1), 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 //labuilds01/c$/GIT
>  ! [remote rejected] master -> master (branch is currently checked out)
> error: failed to push some refs to '//labuilds01/c$/GIT'
> C:\GITtest>
> On Thursday, March 12, 2015 at 4:42:36 PM UTC-7, William Lasiewicz wrote:
>> I have been trying to set up get and have it actually work.
>> So far pretty much crap.
>> Here is what I do
>> Set up a Git repository on my server
>> Git Init
>> From my machine,  I go a GIT Pull and point some directory
>> I add some files to that directory
>> GIT Submit, with some stupid comment so it works
>> GIT Push,  this usually breaks and tells me it can't push because the
>> branch is checked out.
>> All I want to do it create a repository on the server,  add some files
>> locally from my machine,  push and go to another machine and actually see
>> those files.
>> In any other tool,  this is completly easy, but in GIT,  there is about a
>> 50% you are going to lose everything.  How in the hell can this be so
>> popular?
> --
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> For more options, visit

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to