"This repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/pre-push."
I've never heard of git-LFS, much less installed it, before. This repository was pushing to heroku just fine for 2+ years.
I recently made a new fork so I could try upgrading to rails 5.2 and ruby 2.4. I got it all sorted and pulled my master FROM that fork, so my master is now rails 5.2 and ruby 2.4.
But I can't push it to heroku because of the above error.
I have no idea where git-LFS came from. I never installed it, and now I don't know how to get rid of it.
If anyone knows why I can't push to heroku, or how to disable this git-LFS (that feels like malware), please let me know! I've been searching for hours :(
Git LFS is an extension to Git that provides better handling of large files than native Git. When you use it in a repository, it installs hooks to ensure that the LFS files are pushed when you push your repository.
You should check your repository for a .gitattributes file. If there is one, and it contains entries that say filter=lfs, then your repository is using it to store large files. If not, then you can fix this by removing the hook in .git/hooks/pre-push, as the message says.
You haven't specified what operating system you're using or where you get your software from, so I can't tell you how it likely got installed, but it is currently removed from your system, which is why you see the message. It may have been installed through your system package manager, such as dpkg or Homebrew. If you're running on Windows, it's shipped as a standard part of Git for Windows.
I'm on a Mac. It really was as simple as deleting that file. It didn't occur to me at first that it was literally just a file in a folder on my hard drive because files and folders don't start with a period. And everything I'd read said to delete it from my repository; I read that and I'm thinking it's on github somewhere, not my local drive. Then I looked in my app's folder and saw a .git folder at the top, and from there it was obvious.
Related
I have a problem with Gitlens extension. Firstly, Gitlens or Git History extension is working fine on any other project except the this Laravel project. My problem is, can`t see the file history or line history in this project.
On the other hand, there is no problem in the git log (Git History Extension) as seen in screenshot;
But I can't compare any files with their any version (every commit seems like in the ss). I have no idea what the problem is about.
Lastly, I don't think the problem is about extension settings because other projects do not have this problem. Is there a any chance to fix this issue without resetting git history?
I am answering after 3 months, maybe it works for someone. As I mentioned in the title, surely there is no problem about extension settings for this specific project. The problem is just about git files. Maybe, I damaged some git files while moving the project on my desktop :)
So, there is no chance to fix this issue without resetting git history or starting fresh with git, if you`re having the same problem.
Do not play with git files, it`s no joke!
I've got a similar issue. My problem is in using symbolic links for folders.
I have this folder symlink for my repos.
C:\>dir
Directory of C:\
27.09.2018 21:07 <JUNCTION> repos [C:\Users\Qwerty\repos]
(GitLens v11)
The top editor is opened via C:\repos
The bottom editor via C:\Users\Qwerty\repos
You can see that some git features still work (yellow), but others don't.
However, this is very strange, because in my other repos, I have never observed such issues.
Also notice below that it is still possible to invoke the same action via a git lens popup and then it is possible to use the Prev Next Revision buttons.
Anyway, after more testing, I actually observe the same thing in my other repos. I assume that something must have changed between versions as I only observe these issues for last maybe 2-3 months. I even submitted a ticket that GitLens stopped working in v12.0.0 and later versions https://github.com/gitkraken/vscode-gitlens/issues/1979
The buttons completely disappeared and even the commit information
v11
v12
And Now actually, after having reopened my repo via original path and after updating GitLens back to v12.0.6 I see that it is working properly!
Bottom editor is opened via C:\repos symlink.
I have used Git on Windows for a while, but recently changed the setting and got this.
On almost every command for Git Bash (also on PowerShell and Github Desktop) I get
git.exe is being downloaded on OneDrive
(translation may not be exactly the same)
The setting that changed recently is moving my repos to a OneDrive folder in order to have them synced between two sessions: that is work desktop and remote virtual machine.
I can see that this may not be ideal, but it really works for me since I have the same settings on both sessions, and not really get used to doing many commit-push-pull. Not the main topic here, but feel free to comment.
(Edit): Upon reading solution, there are other ways to set this syncing that doesn't mess up with the internals of Git. Look for that instead. Thanks.
In any case, the strange thing is that the notifications happen only on the Remote Virtual Machine, but not on the desktop.
I have seen some notifications about some files in the repos, which I then attribute to OneDrive being nosy about every move I make file I move. But then I've also seen files I don't know about, and theres always git.exe attached to the notification.
In the first scenario I have tried tuning down the notifications for OneDrive. Some might say Microsoft does have a background for not letting users setup their notifications, so I'm still looking.
Thanks.
Most file syncing tools like OneDrive and Dropbox operate by syncing data file by file. This is a great approach if you're working on a single word-processing document or spreadsheet. However, it's not as great when you're working with a Git repository.
When changing between branches or making a commit, Git changes and creates a lot of files all at once. In order to be synced correctly, all of the created files must be written in a similar order: all the blobs must be written, then the trees, then the commits, and then the refs can be updated. If you do this out of order, your repository can be corrupted, since you can have branches that refer to objects that don't exist (or objects that refer to other objects that don't exist).
In addition, these tools can end up deleting files you wanted to have in your working tree or recreating files you didn't. So overall, you don't want to sync any Git repository using one of these tools.
You can write a bundle file with git bundle and sync that, or you can use rsync to sync a repository provided it's idle (not being modified) when you do. Note that if you sync a working tree, Git will need to refresh all files when you sync it across to the new machine, and also Git doesn't try to defend against untrusted users who have access to the working tree.
It's also not a good idea to sync your Git installation itself via OneDrive, which is what it sounds like might be happening. Instead, install Git for Windows on each machine independently and don't try to sync it across. OneDrive should have configuration options that let you control what's synced.
I think I've done something rather stupid which may have cost me a couple of days of work. What follows is a question not so much about GIT itself as how to recover some files I have lost in the process of trying to use Git on a Mac.
I have been using Atlassian Sourcetree to make Git commits and pushes and to work with other members on a team. I have only been committing, pushing and pulling from Git.
As I've mentioned, I've been using SourceTree, but I wanted to evaluate Github for Mac as well.
At the time, I had made some changes to the files in my Git repo, representing about six hours of work. I did NOT commit or push these changes.
After I installed Github, I stupidly set Github to clone the repo to the same folder on my Mac as I had been making my changes in... essentially, Github downloaded the repo and overwrote all of my changes.
There were some files that were overwritten, and some new files that I created that were deleted.
Is there is a way to retrieve these files, either by some Git-based voodoo or some aspect of Mac OS X journaling that I'm not aware of? I would really appreciate hearing about it if there is.
So, from what I remember from having my life destroyed by my stupidity with git, it has a place where you can find your old code.
Go to your main repo folder and then type cd .git/lost-found/other/ or cd .git/lost-found/
You should be able to find a set of files that were older and you can then manually get them back by copying them in.
Here's some more links on it :
Recovering added file after doing git reset --hard HEAD^
Undo a git pull
http://www.quora.com/Git-revision-control/How-can-I-recover-a-file-I-deleted-in-my-local-repo-from-the-remote-repo-in-Git
I like to keep my local Git repos in my Skydrive folder so they sync nicely between machines and I always have an online copy. However, I've recently run into problems after upgrading from Windows 8 to Windows 8.1.
Specifically, I started getting errors that [hash] object was missing or corrupt. After debugging the issue, it turned out that Git was having difficulty with 8.1's new Skydrive integration into the file system. Specifically, 8.1 likes to list files as if they're stored locally, but keep them online until they're accessed. It turned out that right clicking my repo folder and clicking 'make available offline' solved the git errors.
Is there some convenient git or windows setting that I can change to make this unnecessary? It's not a big deal to make files available offline (in fact, I'll probably do that anyway), but I'd like to know if there's a neater solution.
You don't keep a git repo in a synchronized folder (Dropbox, SkyDrive, ...): too many files, too many corruption possibilities.
What you keep is a bundle:
one file
which can be incrementally updated,
and which represents your git repo
and from which you can clone a local repo
See:
"Git with Dropbox"
"Using Dropbox to synchronize files and having them backed up in version control"
"Git with Dropbox Issues"
Or, you can push those repos to a private repo hosting service like BitBucket, as commented by ta.speot.is.
I'm seriously about to stop coding and become a carpenter. This problem has had me stressed out for quite some time now and there doesn't seem to be any clear solution, other than forcing non-windows machines to use the file permissions windows seems to inflict.
Let's begin with the scenario. I have 2 development machines, one running Windows7, the other Mac OSX. They both are using Eclipse and EGit, and both have cloned the same project from a remote repo. That's where the similarities end, because my windows machine has a nasty habit of retaining a file mode of 644 (r-xr--r--) on its local repo, while the mode on the Mac defaults to a cool 775 (rwxrwxr--x).
So the problem's obviously the file permissions - GIT reports there are files that have changed due to differences in file modes and not actual content. The solution seemed obvious, run the following commands:
git config core.filemode false
git config --global core.filemode false
...which worked like a charm, except when committing and merging resolved conflicts.
For example, say files A, B and C exist on both the Windows and Mac repos. Next, let's change the file mode for these 3 files on the Mac machine so that the developer can edit them. Now change some of the contents in file A. Because we're ignoring the file modes (thanks to the commands above) only file A will be committed and pushed, ready for the Windows machine to fetch, merge and enjoy...
Now, let's edit file A again on the Mac and on the Windows machines, effectively causing a potential conflict, and let the Windows machine commit and push file A first. Then, when the Mac user commits their changes to file A and fetches the latest changes from the remote repo, a conflict is obviously created.
After resolving the conflict on the Mac machine and adding file A back to their local repo, committing that merge includes the previously ignored files B and C, and thus highlighting my problem! Why are the previously ignored files being included in this merge commit? This doesn't seem to be a Mac / Windows problem exclusively, as this problem can be recreated both ways...
This probably wouldn't matter if there were only 3 files, but this project I'm referring to includes thousands, and all these up and down push and pulls are insane. Am I missing something really obvious? Any help will be greatly appreciated!
So after a long and often frustrating run with trying to get Windows and Mac OS machines to like each other when comparing notes and changes over Git, it seems to just be the functionality of Git itself that's driven me mad, and a better understanding of how to better use Git seems to be the final answer.
Originally, I wanted to know how to continue ignoring file-mode changes (which Windows seemed to love updating with its own idea of what permissions and modes should be) while I was resolving conflicts created from updates to the files from someone else. Short answer: you can't. It's just the way Git works.
So how would you deal with this situation when it came up? Short answer again: use branching.
In my original way of using Git, I was continually working on my master branch on my local repo - bad idea already - so all my work would be committed there and all conflict resolution would need to be handled there too, forcing all files to be compared again and all permissions and file modes to come into question.
With branching, you work on another branch, commit to that branch, pull updates to your master branch, and merge you other branch with your master branch after that. Suddenly no more conflicts on the master from the remote repo, and you're winning!
Commands to do this (creating a branch from currently selected branch):
git branch newbranch
To checkout your new branch:
git checkout newbranch
To merge your new branch with your master branch (after you've committed to your newbranch, switch to the master first):
git checkout master
git merge newbranch
Hope this helps someone! -:)
well tbh, I'm not sure how you arrived at your conclusion since the obvious problem is git is not ignoring the file mode changes. This happens to us here too.
if you set that flag it seems to make no difference in some cases and still uses file modes to determine changed files.
that has to be a bug in git, what else could it be?
possibly your answer does not explain the rationale, therefore I dont think it's the correct answer, it's a workaround.
the correct answer is that git doesnt use filemode when it's told not to, it's obviously ignoring that and doing it anyway.
can you explain otherwise.