I was unable to git commit on an old Synology DS-106j for a while. After asking this question here a while back, I followed the suggested alternative till I found out that I now need to use git on the platform. (I am currently writing a program for it.) Fortunately, I found a way to get an updated version of git for the platform, but the issue is still there even after the update. Below is a short version of what happened:
git init
git add .
git commit -m "Testing"
fatal: d7fae4dbad5534fed92205ff4a9cc1152b013c8b is not a valid object
I tried again by deleting the .git directory; yet, the similar result shows. In the previous question, it is possible that it may be a version problem since I was running git version 1.8.4.2-1, but the problem still persist after updated to version 2.3.7.
The strange part is that I tested git version 2.3.5 on a newer Synology DS-212j and it works perfectly fine. Maybe that my old platform is missing a dependency or something of that sort?
Related
I have a VPS running a Node.js / React app.
I want to update the files in the vps each time I push data to the git(hub).
I found out, using this answer, that I can add some hooks in git, executing commands on "post-receive".
What I didn't quite understand :
Why did he init another git ? Couldn't he have done this in the .git directory and create the hooks/post-receive file?
Why git checkout -f ? If the goal is to update local files, so nodemon / create-react-app restarts the server / app, why not execute a git pull instead ?
Is there a better way of doing this ?
In the recommended answer there, nobody is using GitHub and there is no other Git repository yet. So the answer to your question:
Couldn't he have done this in the .git directory and create the hooks/post-receive file?
is: No, there was no .git directory in the first place. The target machine had nothing at all, no Git repository, no working tree, etc. The git init --bare created the Git repository (the ".git directory").
The git checkout -f is a poor-man's / low-quality implementation of push to deploy. A receiving repository is normally "bare", and this one is no exception.
why not execute a git pull instead ?
That would require creating a third Git repository. That would have been an option.
"Better" is in the eye of the beholder. There are many ways of doing this, each with its own pluses and minuses. See also Deploy a project using Git push, which notes that since Git 2.3, receive.denyCurrentBranch = updateInstead is available; it was not available prior to 2015 (and in 2015, many people had older versions of Git installed).
Note further that if you're using GitHub as a hosting system, this changes a number of variables. The questions and answers you and I have linked here are aimed at those not using GitHub.
I am running my own instance of a Gitlab-CE server with the following fairly-up-to-date specs:
Gitlab Version 10.8.4
Gitlab Shell 7.1.2
Gitlab Workhorse v4.2.1
Now my problem is that when I add a message to my commits referencing an issue, there is no commit mention in the issue as there should be.
As an example: git commit -m "handled issue #12" and the obligatory git push does not add anything to issue 12.
Any idea as to where the problem could be?
Edit: added the information that I am already pushing to the remote.
Found it: turns out that I had forgotten to change back my email adresse back to the one used in the remote repo – I had it changed locally a few weeks ago to test s.th.
So due to using my ssh key committing worked, but it showed the wrong user in my commits (which should have been a good hint for me as to what's up...) and due to that user not being a member of the project I had no access to the issues (at least that's my conclusion here).
Hope this might help anyone silly enough to run into similar issues...
git commit just creates a local commit in your branch. If you want GitLab to be aware of it, you need to push it:
$ git push origin my-branch
One project of mine stopped showing history or reacting to push events in any way after upgrading to gitlab version 8.3.2 (but it could also be on previous versions as we update frequently).
I'm using a plain gitlab docker installation. Is there a way to let gitlab reload the commit history ?
UPDATE:
This is happening on serval projects not just one, but until now there's no common factor between them apart from having recently enabled CI and being imported from an external git repository.
Finally I got it!
The cause of this behavior was that the git repository was imported with the wrong directory structure.
It was:
repository.git/
|
+-> .git/<bare-repo-content>
Instead of just:
repository.git/<bare-repo-content>
The fix was to simply rename and move the bare repo:
mv repository.git/.git tmp.git
rm -rf repository.git
mv tmp.git repository.git
We have a serious problem with foresight linux. As we know it, foresight has no support due to the conary package method which is shutdown now. However in our application the build fails because the online repo is not reachable (rpath).
This is the error we get during build:
Error occurred opening repository http://foresight.rpath.org/conary/: Connection refused
So we found a way to get a list of conary packages on the local server as a dump(from git - mirror of conary repo).
Now we are really not sure on how and where to update foresight Linux to look over new repo path instead of foresight.rpath.org/conary.
The fact is that we would not expect any major upgrade or update on the packages. This is to let build run without getting exit saying online repo issue, so that we can plan and manage until the application gets completely migrated.
You can edit the repo list by yourself, the path is
cat /etc/apt/sources.list
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