i have a weird issue. Im using TortoiseGIT (Win7) and my repositories are placed on a vritual server (Debian), where im using gitolite and SSH keys.
I can clone the repository to my PC, i can run Fetch, Push, Commit, Sync .. everything, but when trying to Pull the changes from server Pushed by other contributor, the following error appears:
git.exe pull -v --progress "origin"
fatal: 'pull' appears to be a git command, but we were not
able to execute it. Maybe git-pull is broken?
git did not exit cleanly (exit code 128)
I don't understand, why just the pull command is not working .. thanks for any help.
I can make a clone of the repository, with the contributed changes .. but can not Pull the changes to created repository on my PC.
I encountered this same issue after changing the git Bash executable sh.exe to be always run as administrator (to get round another problem). It then left git unable to access it under certain scenarios and caused various "Maybe git-* is broken?" errors. Perhaps this might help someone...
Uninstalling old Git and reinstalling the latest build fixed this issue for me.
Here's a link to the installers
Link to get installers
My exact error message was
C:\Program Files (x86)\Git/libexec/git-core\git-pull: line 304: exec: git-merge: not found
fatal: 'pull' appears to be a git command, but we were not
able to execute it. Maybe git-pull is broken?
The error message is very much linked to Git, and comes from help.c:
static const char bad_interpreter_advice[] =
N_("'%s' appears to be a git command, but we were not\n"
"able to execute it. Maybe git-%s is broken?");
That is similar to issue 40 (of another GUI, here terminal-ide).
In that case, it was due to the remote Git installation, which was incomplete
(Comments 3 of issue 19)
git-merge was also missing from install, can be fixed with
$> ln -s git git-merge
in system/bin/
The resolution might not be exactly the same in your case, but it could be related to a faulty Git installation.
I see that you're able to run "git fetch". If you can also run "git merge", running the sequence "git fetch" followed by "git merge" will accomplish the same thing as "git pull".
Source:
http://git-scm.com/docs/git-pull
Related
I have received a gitlab alert mail stating that "One project failed its last repository check".
I did check the error in Gitlab admin panel as "Last repository check (just now) failed. See the 'repocheck.log' file for error messages." As suggested in Admin Panel in Gitlab, i have checked the repocheck.log file and the error is as below.
"Could not fsck repository: error: Could not read 0f188244898707e6090498bc03aafd8ac25e776e
failed to parse commit 0f188244898707e6090498bc03aafd8ac25e776e from object database for commit-graph
error: Could not read 4ab7111f3f8f1083cee8e33ec033c18edfefb0e9"
This happened the same with another repo last week. Even that had similar error message and it is not resolved yet. Tried to clone the same repo in another gitlab instance to recreate the issue but the repo check there seems to be fine.
Unable to find proper solution for that. Could any one please help on this.
It seems to be an active issue: https://gitlab.com/gitlab-org/gitaly/-/issues/2359#note_966195929 The issue is a couple of years old, but the note I link to, has updates from today, including info on fixes and workarounds.
In any case: The commit-graph is a relatively new feature and since it is a form of index into packed data, it can be recreated. So the corrupted repo can be easily fixed without loss of data.
It can be reproduced like this:
Visit a commit graph: Project sidebar / Repository / Graph
Delete one of the visible commits by rewriting history:
git checkout <branch>
git reset head~1
git commit -am "Replace last commit with a new one"
git push --force
Refresh the page of step 1
Now GitLab will send you "A commit graph at GitLab projects failed their last repository check" when it runs the repository check on a scheduled interval.
I'd consider it a bug that admins and maintainers get a warning about this, since nothing is wrong really. See the GitLab issues linked by Anders Bandholm for more details.
I've now come across and fixed this twice, I found the fix on the forum:
Find all your failed repos at your instance's admin panel: https://your-gitlab-instance/admin/projects?last_repository_check_failed=1
Open the repo from that page and copy down its Gitaly relative path, it should look like #hashed/d4/73/c530f048efdf2711df6fa15198ff48003583303624f8b97c174fadc2cab5e582.git
NOTE! The following commands should be run with the user that gitlab runs as. You can do this with sudo su [username], in my case the username was git. They will work with sudo, but it may create files or folders that the gitlab user won't be able to access.
Run the fsck command using the repo's relative path (This should output the same text as your /var/log/gitlab/gitlab-rails/repocheck.log file):
/opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/[Gitlab relative path] fsck
# example
/opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/\#hashed/d4/73/c530f048efdf2711df6fa15198ff48003583303624f8b97c174fadc2cab5e582.git fsck
Run the gc command using the repo's relative path. This may take a minute to complete.
/opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/[Gitlab relative path] gc
# example
/opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/\#hashed/d4/73/c530f048efdf2711df6fa15198ff48003583303624f8b97c174fadc2cab5e582.git gc
Run the fsck command again from step 3 to check that the command was successful
On the repo's page from step 2, click the blue Trigger repository check button
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?
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'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 ./