So I'm just learning Git, and can't tell what I'm doing wrong in setting up a local and remote repo for my scripts. Originally, the remote repo was going to live on a fileshare (\server\share$\scripts), but I can't even seem to get this to work on my local machine.
I've done my research, and read up on some of the common pitfalls, but I still can't seem to get files accurately reflected in my remote repo when pushing from the local one.
What I have:
Local Repo: In C:\git, with one file "test.txt" created by:
cd C:\git
git init
echo "Hello World" > test.txt
git add .
git commit
Remote Repo: C:\test
git --bare init
Then, when I specify a remove branch with:
git remote add origin C:\test
git push origin master
It tells me all is fine:
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 315 bytes | 315.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To C:\test
06e076a..62b6130 master -> master
And further git pushes return "Everything up-to-date", but the files are never pushed to the remote repository. Querying the logfile indicates that the push did in fact take place:
commit 62b6130cedef529ef97aec5333fcbee96c5e9a2f (HEAD -> master)
Author: [Redacted]
Date: Wed Jan 24 15:21:37 2018 -0500
TEST COMMIT
So where are the files? I'm on the right branch (master), and I even ran a git config receive.denyCurrentBranch false because some other similar threads suggested this as a fix.
Looking for some guidance here, appreciate any and all help!
Your remote repository is a bare repository. This means there simply is no checked out working tree. Just the git objects and branches and tags.
Having a working tree (aka your files in the most up to date master branch) doesn't make any sense for a remote repository. This is where you store all versions of all your files in one place. How should git know which branch/version/commit to use in the working tree?
I also found this description: Source
git init is for working
git init --bare is for sharing
To get your files back again, you need to clone from there.
git clone C:\test .
This will create a new repository with working tree.
Here are some links:
What's the -practical- difference between a Bare and non-Bare repository?
http://bare-vs-nonbare.gitrecipes.de/
Related
I'm trying to set up a vanilla new separate repository for the first time with git 2.37.1 on two W10 systems using drive mapping but I can't find any answered questions that fit my case given my novicitry. :-) Sorry the format is messed up, I did 4 spaces in front of code but most code lines ignore that for some reason.
Spent hours looking at other similar questions, but they all seem to say that there are no commits in the remote repository I'm trying to clone, which is not true. There are lots of commits.
I created a git repository on System1 and it works.
git ls-tree --full-tree --name-only -r HEAD
shows all my files (with lots of commits)
git show HEAD
shows
commit 557...27d (HEAD -> master)
# and the diff between the latest and previous commit
And
git branch -a
shows
* master
No branches, no complexity, no nothing
I go to System2, and create my repo directory, cd into it, then
git init
git remote add origin s:/cap2office # that's my mapped System1 repository)
git pull origin master
I get: fatal: couldn't find remote ref master
git remote
I get: origin
git branch -a
shows nothing
git ls-remote
shows: From s:/cap2office
I also tried:
git clone s:/cap2office
and it says
Cloning into 'cap2office'...
warning: You appear to have cloned an empty repository.
I know I'm missing some trivial magic command, but can't figure out what it is.
You are not cloning a repository, you are trying to clone the working directory of a git clone.
The git repository is stored in the .git folder inside the working directory.
Try this:
git remote add origin s:/cap2office/.git
On system 2, instead of doing git init then git remote add and git pull, do just this:
git clone s:/cap2office/.git
or if you're in Git Bash, sometimes the colon does not work so you need
git clone s/cap2office/.git
Then you can cd to the folder where it was cloned and do the usual git status, git checkout, change stuff, commit, and push to the remote.
So, I've created a git repository on the networked drive:
git init --bare --shared
and that works fine. Then, I clone it to a local drive with
git clone z:/testgit
and that also works fine. Then I add a file, stage, and commit
git stage *
git commit -m "test commit"
and that ALSO works fine. BUT! When I try to push to the origin, I get this error.
git push origin
Counting objects: 3, done.
Writing objects: 100% (3/3), 225 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: error: unable to write sha1 filename ./objects/f3/e6e90a7465421306fae05c18153260973542e3: Permission denied
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To z:/testgit14
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'z:/testgit'
When attempting to use git stage * directly on the server (on a non --bare git project) I get similar errors.
I have full access to the drive in file explorer, and even able to initialize the repository with git. SSH shouldn't even apply here since it's not a server, it's a networked drive. Everything I've read about git says that this should work. I've read dozens of "how to's" that all say these exact steps, but no one complaining about permission denied, UNLESS they're talking about SSH public keys missing on servers (which, as I've said, shouldn't apply).
What permissions am I missing? Where should I look for and set the proper permissions?
What happens when you try to create the file that git is complaining about?
echo test > ./objects/f3/e6e90a7465421306fae05c18153260973542e3
It's possible that git is creating a new folder (f3) and the folder is not getting the correct permissions, either due to ACL inheritance misconfiguration or because the local machine is trying to adjust the permissions on newly created folders and getting it wrong.
If it were Linux, it could be because the network drive was connected with the wrong mount options, or the umask was set incorrectly, but I'm not sure whether those are available to be changed on a Windows machine.
I created a new file in a local folder monitored by git. I then did
git add .
git commit -m "blah blah"
git push
but was rejected with
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
I tried git pull and got the error
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
which is a bit surprising considering there is only the master branch.
So I tried git pull origin master and something looking like VI with a bunch of empty lines opened up wanting me to resolve merge conflicts and it didn't give any information.
I just want to push changes to the repo. I'm the only one working on this personal project. I'm using Windows 10 and the official git bash. How do I git over this problem?
BUT WAIT!
I tried git pull origin master a second time and it worked! Nothing had been changed. This has happened before and I'd like to know why?
Here's the details:
first git pull origin master gave
* branch master -> FETCH_HEAD
second:
branch master -> FETCH_HEAD
Already up-to-date.
third:
remote: Resolving deltas: 100% (2/2), completed with 1 local objects.
no other commands were run in between. On the first one a bizarre VIM text editor opened up that wanted me to type something in.
remote: Resolving deltas: 100% (2/2), completed with 1 local objects.
After updating to the latest Windows Git (2.5.0 from 1.6.2) I find I'm unable to rebase a branch:
C:\core\guidewire\Dev\2.4>git checkout fhcf-assumptiondate && git rebase master
Previous HEAD position was d032e17... Merge branch 'de8041'
Switched to branch 'fhcf-assumptiondate'
First, rewinding head to replay your work on top of it...
fatal: C:\Program Files\Git\mingw64/libexec/git-core\git-am cannot be used without a working tree.
Comments on this question hint at a Git installation conflict, but the old version is entirely removed by now, including a lingering DLL and checking for stale environment vars.
Looking inside the git scripts, I find that the error message is coming from a test in git-sh-setup that uses git rev-parse --is-inside-work-tree. Consulting rev-parse directly shows that it seems to not understand that I really am inside the working copy:
C:\core\guidewire\Dev\2.4>dir .git
Volume in drive C is System (Local)
Volume Serial Number is D4EC-4ED4
Directory of C:\core\guidewire\Dev\2.4
08/04/2015 21:16 27 .git
1 File(s) 27 bytes
0 Dir(s) 155,451,965,440 bytes free
C:\core\guidewire\Dev\2.4>git rev-parse --is-inside-work-tree
false
...Except some commands are able to correctly tell the difference:
C:\core\guidewire\Dev\2.4>git status
HEAD detached from refs/heads/fhcf-assumptiondate
nothing to commit, working directory clean
C:\core\guidewire\Dev\2.4>cd ..
C:\core\guidewire\Dev>git status
fatal: Not a git repository (or any of the parent directories): .git
What is making Git confused about whether I'm in the right directory or not?
Possible points of interest:
Repo was created by the previous installation.
1.6.2 was an msys build of Git. 2.5.0 is MinGW.
The repo was cloned with --separate-git-dir.
checkout, status, add, commit and possibly others all have worked without issue since the upgrade.
A clone of the broken repository exhibits correct behavior; 'in' or 'out' of the working tree are detected correctly.
To continue using an existing (1.6.x-created) repository after upgrading to Windows Git 2.5, update the repo's gitconfig:
[core]
worktree = c:/core/guidewire/Dev/2.4
to
[core]
worktree = C:/core/guidewire/Dev/2.4
The new Git installation either obtains paths differently from the old, or is no longer case-insensitive about paths. Therefore the existing repo working tree location becomes wrong since no folder under c:\core\guidewire\Dev\2.4 will have a prefix of C:\core\guidewire\Dev\2.4. Git source for the current version shows no sign of case-insensitivity, so the msys fork may have modified the path-checking function, or case-smashed all paths prior to comparison.
So I have been having troubles pushing my most recent commits to a remote repository that I have set up on Bitbucket.
I am originally using Xcode, and have asked this question and was recommended to use terminal to push instead of Xcode.
Now, I tried terminal but that did not solve the problem. But it did give me a more detailed error message when I try git push
Neils-iMac:ProjectName Neil$ git push
Password:
Counting objects: 49, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (39/39), 975.78 KiB, done.
Total 39 (delta 31), reused 0 (delta 0)
error: RPC failed; result=55, HTTP code = 0
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
fatal: expected ok/error, helper said '2004\??? ?&?ЇҶ-9?u?r?m?v?ǣ3Ƅ:??Eƒ?=?&?"d?+??
*^?eA??/3cv????ʞe??f???????
?(??`}D???5???^:T??PxP????%?338?]??F?}???Gf?g??[??*??}zƈ1X'
Neils-iMac:ProjectName Neil$
Neils-iMac:ProjectName Neil$
I am new to these remote repositories, and had everything working fine on Xcode, so if you recommend for me to do something in terminal it would help if you described how to do so.
See my previous question for a bit more detail.
EDIT: This is the result of;
git status:
# On branch master
# Your branch is ahead of 'origin/master' by 5 commits.
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# CrunchCalculator.xcodeproj/project.xcworkspace/
# CrunchCalculator.xcodeproj/xcuserdata/
nothing added to commit but untracked files present (use "git add" to track)
git remote show origin:
HEAD branch: master
Remote branch:
master tracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (fast-forwardable)
Looks like you are trying to push a large delta and your push buffer is not big enough
Try this:
git config http.postBuffer 524288000
I had the same problem and git config http.postBuffer 524288000 worked for me.