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: http://git-scm.com/book/en/v2
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 <lasiew...@gmail.com> 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 git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
