Delete git LFS files not in repo - linux

I uploaded some files to git LFS and I went over my storage limit. Now, the files I uploaded don't show up in the repo, but I'm still over my data limit and I can't upload anything.

Deleting local Git LFS files
You can delete files from your local Git LFS cache with the git lfs prune command:
$ git lfs prune
✔ 4 local objects, 33 retained
Pruning 4 files, (2.1 MB)
✔ Deleted 4 files
This will delete any local Git LFS files that are considered old. An old file is any file not referenced by:
the currently checked out commit
a commit that has not yet been pushed (to origin, or whatever
lfs.pruneremotetocheck is set to)
a recent commit
for details please go through this link https://www.atlassian.com/git/tutorials/git-lfs

Currently that is not possible via lfs command line. From the Atlassian Git LFS tutorial:
The Git LFS command-line client doesn't support pruning files from the server, so how you delete them depends on your hosting provider. In Bitbucket Cloud, you can view and delete Git LFS files via Repository Settings > Git LFS
GitHub even suggest recreating the repo:
To remove Git LFS objects from a repository, delete and recreate the repository. When you delete a repository, any associated issues, stars, and forks are also deleted.
But it is still good idea to use tools like BFG to clear out large files in history before moving around.

Related

How to prevent Git from storing copies of LFS files in .git dir?

It seems that Git is storing copies of LFS files in .git/lfs. This is taking twice of the space. I know this is a typical way Git handles the files, but I'm still wondering if there is a way to prevent Git from caching copies of them and just download from cloud when trying to revert the files.
If the files are in the lfs folder, it's that git needed them at a moment to populate your working directory.
So, no, there is no way to prevent git to cache them (except maybe by doing a sparse checkout if you really don't need to have the files handled by git-lfs in your working directory).
But you have an easy way to clean this cache directory (git will keep only the currently used files and delete the others unused) with the command:
git lfs prune

git-repo (aosp repo) tool checking-out projects again from local cache

We use the google git-repo tool (aosp repo) to manage a workspace of many git repositories. However, if you want to do a clean checkout that is exactly the same as the last workspace, using the command repo sync will pull in all the changes from remotes first.
How can you get the local repositories populated from only the local cache that is currently in the .repo/ directory?
You can use:
repo sync --local-only
From repo help:
$ repo help sync
[...]
-l, --local-only only update working tree, don't fetch

git only clones sha for LFS files on Gitlab CI

I pushed .png files, each of which is 2+MB file size and tracked by git-lfs, to my gitlab.com repository, say repo_a. In CI job on another repo repo_b where git-lfs is installed, repo_a is cloned. Now I see the size of all .png files are 132, which seems to be the same volume as sha output (as the following. Note: some values are populated for privacy):
$ git show HEAD:file-a.png | tee sha_temp
version https://git-lfs.github.com/spec/v1
oid sha256:shashashaaaashashashaaaashashashaaaashashashaaaashashashaaaa
size 2430019
$ ls -l sha_temp
-rw-rw-r-- 1 crookednoodle crookednoodle 132 Nov 7 05:35 sha_temp
However, On my computer instead on Gitlab CI, I can see the original files when I git clone the repo_a.
This makes me feel that the content of these files are still pointers, not the original files. I also noticed that on my computer, I see in the output the original files are downloaded like this:
Downloading file-a.png (2.5 MB)
But I don't see this in the output on CI job.
Obviously related, subsequent process that opens the images by OpenCV fails.
What is wrong?
Managed to solve (get around) the issue by myself. In the targeted repo, I modified the CI script to run git lfs pull.

What is wrong with my git 1.8.4.2-1?

I have an old Synology DS-106j server where I tried to install git using ipkg command. The installation went smoothly, but git failed to work correctly. I am currently learning how to use git, so I don't know if it is a bug from git with the version I am using or something else is wrong.
What I did was create a new local repository with a specified name, add a new file, commit it, and got an error:
NAS_SERVER> git init Test
Initialized empty Git repository in /root/Test/.git/
NAS_SERVER> ls
Packages.gz git_1.8.4.2-1_powerpc.ipk
Test
NAS_SERVER> cd Test
NAS_SERVER> git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)
NAS_SERVER> touch Test.cs
NAS_SERVER> ls
Test.cs
NAS_SERVER> git add *
NAS_SERVER> git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: Test.cs
#
NAS_SERVER> git commit -m "Test"
fatal: 57e2b8c52efba71d84c56bf6f37581686b9061a3 is not a valid object
I thought...maybe I did something wrong, so I used git on Windows OS and try a push. Still an error. Transfer the whole repository to the server and check the status. It seems fine. Try a commit. Still the same result. What worse is that I can't update git version without having to compile it, which I don't even know how to do so. Any suggestion to what might be wrong?
If your goal is to push into a git repo located on the synology disk(s) for backup purposes I'd recommend a different approach which would avoid having to install a rather old git version on the synology box itself (which could lead to problems if/when using a newer git version on the windows machine).
Export a samba share from synology, mount it on windows and use the windows git to create the backup repo (maybe even a bare repo, eventually group shared if you plan to share work with other people). Then push from your working repo into this backup repo - all on the windows box. In this scenario the synology box doesn't need git installed, it just serves files (i.e. its original job).
I'm using such setup but with a linux machine instead of a windows one and with the bare repo on the synology disks exported via NFS instead of Samba.

Git - Syncing a Github repo with a local one?

First off, forgive me if this is a duplicate question. I don't know anything but the basic terminology, and it's difficult to find an answer just using laymen's terms.
I made a project, and I made a repository on Github. I've been able to work with that and upload stuff to it for some time, on Windows. The Github Windows application is nice, but I wish there was a GUI for the Linux git.
I want to be able to download the source for this project, and be able to edit it on my Linux machine, and be able to do git commit -m 'durrhurr' and have it upload it to the master repository.
Forgive me if you've already done most of this:
The first step is to set up your ssh keys if you are trying to go through ssh, if you are going through https you can skip this step. Detailed instructions are provided at https://help.github.com/articles/generating-ssh-keys
The next step is to make a local clone of the repository. Using the command line it will be git clone <url> The url you should be able to find on your github page.
After that you should be able to commit and push over the command line using git commit -am "commit message" and git push
You can use SmartGit for a GUI for git on Linux: http://www.syntevo.com/smartgit/index.html
But learning git first on the command line is generally a good idea:
Below are some basic examples assuming you are only working from the master branch:
Example for starting a local repo based on what you have from github:
git clone https://github.com/sampson-chen/sack.git
To see the status of the repo, do:
git status
Example for syncing your local repo to more recent changes on github:
git pull
Example for adding new or modified files to a "stage" for commit
git add /path/file1 /path/file2
Think of the stage as the files that you explicitly tell git to keep track of for revision control. git will see the all the files in the repo (and changes to tracked files), but it will only do work on the files that you add to a stage to be committed.
Example for committing the files in your "stage"
git commit
Example for pushing your local repo (whatever you have committed to your local repo) to github
git push
What you need to do is clone your git repository. From terminal cd to the directory you want the project in and do
git clone https://github.com/[username]/[repository].git
Remember not to use sudo as you will mess up the remote permissions.
You then need to commit any changes locally, i.e your git commit -m and then you can do.
git push
This will update the remote repository.
Lastly if you need to update your local project cd to the required directory and then:
git pull
To start working on the project in linux, clone the repo to linux machine. Add the ssh public key to github. Add your username and email to git-config.
For GUI you can use gitg.
PS : Get used to git cli, It is worth to spend time on it.

Resources