Is this a bad idea or is there a better way of approaching version control for my whole dedicated server?
My first attempt was git init and git push but I couldn't resolve error:
error: src refspec main does not match any
error: failed to push some refs to 'main'
I tried several fixes and workarounds from StackOverflow.
So then I tried creating a repo from GitHub.com with just a test file, then cloning it, cd /, git add ., etc.. but I keep running into errors with it too.
fatal: destination path '.' already exists and is not an empty directory.
..is what I get after running git clone git#github.com:hero/128GB.git .
Any ideas on what I should do next? If I should continue this path or is there a better approach at version control for a server?
Related
I recently updated the development server that hosts our code repos to a newer version of Ubuntu (18.04). As part of the process git was upgraded to version 2.23.0. The actual application servers where the code gets deployed to need to be able to checkout the latest changes from the git repos. When I try to do a 'git fetch' on those servers I get a long list of errors that look like this:
error: index file
./objects/pack/._pack-5b58f700fea57ee6f8ff29514a376b945bb1c8a9.idx is
too small
I did some digging around to see if I could come up with a solution but so far noting has worked. I tried the answers listed here: git error: "index file is too small" .
Neither git index-pack nor git repack -a -d solved the issue. I even tried deleting the local copy of the files from the application server and installing fresh using git clone. The clone itself threw a bunch of errors similar to before
remote: error: index file
./objects/pack/._pack-5b58f700fea57ee6f8ff29514a376b945bb1c8a9.idx is
too small
At this point I'm out of ideas. Any help would be appreciated.
Edit: The output of du -h suggests that there is enough disk space.
The error message sounds like file corruption. If you have not run out of disk space, you can delete the index file and recreate it with:
git index-pack -v ./objects/pack/._pack-5b58f700fea57ee6f8ff29514a376b945bb1c8a9.idx
You might also want to run use git-fsck to
verify the connectivity and validity of the objects in the GIT database -- both the remote the local one.
If your index is corrupt, you can also try to reset the branch which will create a new index file:
To be safe, backup .git/index.
Remove the index file .git/index.
Perform git reset
References
The issue is a possible duplicate of git error: "index file is too small"
Documentation on git index-pack can be found at https://git-scm.com/docs/git-index-pack
Some notes on repairing a broken index: https://makandracards.com/makandra/5899-how-to-fix-a-corrupt-git-index
fatal: packfile name 'server' does not end with '.pack'
I encounter this error when transfer my git repo from Mac OS to another system. Files start with '._' are Mac OS meta files generated by tar command. So look at this question to avoid '._*' files: Tar command in mac os x adding "hidden" files, why?
I am to work on a project and I have initialized a git repo on a server. Let's suppose the URL of the server is
foo.bar
and the repo is at
/var/www/vhosts/foo.bar/httpdocs
I have created a git repo by running
git init
and then I created a .gitignore file, added whatever needed to be added, committed and from my local computer, which has ssh access to the server I have attempted to clone the repo, but I do not seem to find the correct URL or something is not set for the repo. I tried something like:
git clone https://foo.bar/httpdocs/.git
The error was
fatal: repository 'https://foo.bar/httpdocs/.git' not found
I have tried with various pathes.
FYI: I have worked with git a lot in the past, but I have never set up a repository on a server, I have always received the path of repos created by someone else. Now I have created the repo, but I cannot seem to find out what the correct URL is. I have searched a lot to find this out, but unfortunately I did not find anything which would help me. Any ideas?
If you're trying to communicate via SSH, you need the SSH link, not the HTTP(S) link:
git clone <user>#foo.bar:/var/www/vhost/foo.bar/httpdocs/.git
You need git and sshd (or openssh-server) installed on the remote server, and add your SSH key to the server, under the correct user (with ssh-copy-id, of course).
This is pramar error.
The error is in line:
cit clone https://foo.bar/httpdocs/.git
you can try:
git clone https://foo.bar/httpdocs/.git
good luck.
I'd cloned some respositories from github to my local machine (linux x86 32 bit kubuntu 12.04).
In general, I do clone from command line and then connect to eclipse using git perspective and
"add existing local git repository to this view".
After that, I'm able to import projects (from working directory), performing commit and something else.
But when I try to fetch or push against the remote repository, I got some different error messages.
When trying to fetch, I got the error message: Invalid remote: origin
And when I try to push, I got something like: https://github.com/Joe-Merten/Playground: https://github.com/Joe-Merten/Playground/info/refs?service=git-receive-pack not found
Fetch and push via egit definitively has worked until about 10 days ago.
Fetch and push from linux command line is still working without problems.
When trying to clone using eclipse egit, I also got an error like: https://github.com/…/refs?service=git-receive-pack not found
I tried that out with eclipse 4.2 SR2 (Juno) and 4.3 SR2 (Kepler) and 4.4-M6 (Luna Prerelease) on some different linux machines.
Any suggestions?
This could be a credential issue, as mentioned in "An internal Exception occurred during push: cannot store objects":
I just reconfigured the eclipse and added my github account information and store it.
Then it worked.
Team->Remote->Configure push to upstream->URI, Change->Add authentication details
The other classic issue is a capitalization problem in the url ("git-upload-pack not found"), but if it is working from the command line, this shouldn't be the case here.
Ok, it seems that I'd ran into the .git suffix issue.
Solution: I have to add .git to the URI.
Like Lars Vogel wrote in this nice article here: Copy the URL from Github and …,
I'd just used that URI without adding the .git suffix.
So, I'd performed clone like:
$ git clone https://github.com/Joe-Merten/Playground
and that configures my clone to have the following remotes:
$ git --git-dir=Playground/.git remote -v
origin https://github.com/Joe-Merten/Playground (fetch)
origin https://github.com/Joe-Merten/Playground (push)
This way causes the described error messages.
But when I add that .git suffix to the URI:
$ git clone https://github.com/Joe-Merten/Playground.git
my remotes will also have .git suffix
$ git --git-dir=Playground/.git remote -v
origin https://github.com/Joe-Merten/Playground.git (fetch)
origin https://github.com/Joe-Merten/Playground.git (push)
Using this way, egit works as expected.
Looks like that (with or without .git suffix) don't matters as long as I using git from command line.
But when using egit as frontend, this is obviously important.
(Hmm, wondering why that was not a problem until about middle of March 2014.)
So I have been plagued with this weird git problem that myself and a few other developers have not been able to solve. Here it is:
I created a bare repo for managing website changes using git on test server.
For this example the repo is here: /home/website/website.git
The website public root would be here: /home/website
I created the repo by doing this command: git init --bare
inside the git repo directory "website.git"
Next I have my local repo on a machine elsewhere. This is a standard git repo. I build the site get it ready to deploy. When its ready I push it to the bare repo. From my local repo.
There is a post-receive hook that checks the latest file tree out into the public root of the website. So when I change things on the local repo and test them in the localhost environment, once satisfied I can push them to the live server.
Here is the problem I face:
I can push fine. No issues. All works as expected. Code gets checked out to public root. Everybody is happy and goes on with their life.
BUT!!!:
The site is a CMS site. Users log in to it and upload things. Files get created on the public root of the website which is the GIT_WORK_TREE.
So NBD right?! I can just commit the files every now and then from the live bare repo and pull them back to my local environment like I have before. So I log into SSH on the server. Navigate to /home/website/website.git
Then run this command:
GIT_WORK_TREE=/home/website/ git add ../
I get this mess:
error: unable to create temporary sha1 filename ./objects/cb: No such file or directory
error: error_log: failed to insert into database
error: unable to index file error_log
fatal: adding files failed
I have done this before on other servers and it worked fine from what I remember. So I was like WTF, must be something strange on this server. I went to another server I have and replicated the EXACT same steps. Got the EXACT same problem. So now I fear I am loosing my sanity and maybe these previous git experiences are all made up in my head.... *Well, lets not go that far yet.... :)
Maybe somebody can help me out here. I have used git plenty and can't seem to crack this one.
Oh, some other maybe useful specs:
running CENTOS 6.2
I double checked all permissions. I even tried changing everything to 777 recursively just to make sure Im not loosing it somehow. Made sure all the files are owned by the correct user. chowned recursively. I also tried the standard solution to this problem which is described here: https://answers.atlassian.com/questions/132671/git-commit-fails-with-sourcetree-error-unable-to-create-temporary-sha1-filename-git-objects-d8-file-exists
That didnt work either. Not sure where to go from here.
PLEASE HELP ME!!!!
I feel like Linus is playing cruel tricks on me right now.
You have a bare git repository in /home/website/website.git which is inside of a git repository in /home/website? And then you try to trick the bare git repository into having a working tree using GIT_WORK_TREE?
Maybe it is worth understanding this setup but only if you intend to be a git developer. As you are a user focused on delivering website functionality, I suggest using a standard git setup.
Move the bare git repository elsewhere:
$ mkdir /home/repo
$ mv /home/website/website.git /home/repo/website.git
$ cd /home/website
$ git remote set-url origin /home/repo/website.git
I got the solution. This is it. I was running the above command from the git repo.
Turns out the command should be run from the work tree and altered to look like this:
GIT_WORK_TREE=/home/website/ git --git-dir="./website.git/" add ./
I'm pushing to a remote git repo and I get the following on any newly created files
remote: error: git checkout-index: unable to create file
Changes to existing files are accepted, but this is obviously causing issues. Any ideas?
You see this problem when you use Git on a case-sensitive filesystem, then attempting to push changes to a case-insensitive one.
Make sure you aren't trying to commit FOO if foo is already in the repository.