Git LFS

Error converting content: marked is not a function

- #0 Inbox
- TODO figure our how to assess size of commits; my #Logseq repo hit the lfs bandwidth of 1 GB in just 3 days. Something ain't right.
- Jul 15th, 2022
- Git LFS handles large files by storing references to the file in the repository, but not the actual file itself. To work around Git's architecture, Git LFS creates a pointer file which acts as a reference to the actual file (which is stored somewhere else). GitHub manages this pointer file in your repository. When you clone the repository down, GitHub uses the pointer file as a map to go and find the large file for you
- - Setting up lgoseq repo with git lfs to track and store assets
	  id:: 62d1d462-af45-4028-914c-2f28cf6854d7
	  collapsed:: true
  - brew install git-lfs
  - configure git lfs on machine `git lfs install`
  - Track file types that we have in assets folder with lfs. This add to  the .gitattributes file.
  - Note: the extension are case sensitive. Funny. So I also tracked JPG and PNG as I had those files
  - id:: 1e25e2fa-d6fe-466d-b350-8def2b8303f6
			  ```
			  $ git lfs track "*.png"
			  $ git lfs track "*.mp3"
			  $ git lfs track "*.jpeg"
			  $ git lfs track "*.jpg"
			  
			  $ git lfs track "*.JPG"
			  $ git lfs track "*.PNG"
			  ```
  - Since I had existing files of this type. Git stat had the all the files of tracked types modified. 
			  Every file type you want to associate with Git LFS will need to be added with  `git lfs track` . This command amends your repository's _.gitattributes_ file and associates large files with Git LFS.
  - To check tracked files via lfs run `git lfs ls-files`. Also `git lfs track` to see track patterns.
  - To see the lfs url, run  `git lfs env`
  - - Github LFS Storage and Bandwidth: Every account using Git Large File Storage receives 1 GB of free storage and 1 GB a month of free bandwidth. If the bandwidth and storage quotas are not enough, you can choose to purchase an additional quota for Git LFS
  - Git LFS for existing repo.
  - The current setup works for new repos. But as we know the problem with binary files is the git history and cache bloat. For existing repo with assets, we already have these files in the history. This needs to be handled separately.
  - TODO - Just tracking files does NOT convert them to lfs. They are part of history already, the only way to convert old files is to rewrite history (see the section about [migrating existing data](https://github.com/git-lfs/git-lfs/wiki/Tutorial#migrating-existing-repository-data-to-lfs)).
  - - Checkout LFS object
- git auto downloads lfs on checkout
- to exclude some files (very large you don't want) google lfs.fetchexclude
- if you have pointers, then turn to objects `git lfs checkout`
- **Migration**. with `git lfs migration`
  collapsed:: true
- === Migrate unpushed commits
	  
	  A common use case for the migrate command is to convert large Git
	  objects to LFS before pushing your commits. By default, it only scans
	  commits that don't exist on any remote, so long as the repository is
	  non-bare.
	  
	  First, run git lfs migrate info to list the file types taking up the
	  most space in your repository:
	  
	  
	  $ git lfs migrate info
	  migrate: Fetching remote refs: ..., done
	  migrate: Sorting commits: ..., done
	  migrate: Examining commits: 100% (1/1), done
	  *.mp3   284 MB    1/1 files(s)  100%
	  *.pdf   42 MB     8/8 files(s)  100%
	  *.psd   9.8 MB  15/15 files(s)  100%
	  *.ipynb 6.9 MB    6/6 files(s)  100%
	  *.csv   5.8 MB    2/2 files(s)  100%
	  
	  
	  Now, you can run git lfs migrate import to convert some file types to
	  LFS:
	  
	  
	  $ git lfs migrate import --include="*.mp3,*.psd"
	  migrate: Fetching remote refs: ..., done
	  migrate: Sorting commits: ..., done
	  migrate: Rewriting commits: 100% (1/1), done
	    main  d2b959babd099fe70da1c1512e2475e8a24de163 -> 136e706bf1ae79643915c134e17a6c933fd53c61
	  migrate: Updating refs: ..., done
	  
	  
	  If after conversion you find that some files in your working directory
	  have been replaced with Git LFS pointers, this is normal, and the
	  working copies of these files can be repopulated with their full
	  expected contents by using git lfs checkout.
	  
	  
	  ————————
	  
	  
	  
	  === Migrate from Git LFS
	  
	  If you no longer wish to use Git LFS for some or all of your files, you can
	  use the export mode to convert Git LFS objects into regular Git blobs again.
	  
	  The export mode requires at least one --include pathspec, and will
	  download any objects not found locally from your origin Git remote, or
	  from the Git remote you specify with the --remote option.
- # Convert all zip Git LFS objects to files in your main branch
	  $ git lfs migrate export --include-ref=main --include="*.zip"
- # Convert all zip Git LFS objects to files in every local branch,
- # fetching any object data not cached locally from the my-remote Git remote
	  $ git lfs migrate export --everything --include="*.zip" --remote=my-remote
- # Convert all Git LFS objects to files in every local branch
- ==$ git lfs migrate export --everything --include="*"==
- Note: This will require a force-push to any existing Git remotes. Using
	  the --all option when force-pushing may be convenient if many local refs
	  were updated, e.g., after exporting from Git LFS with the --everything
	  option.
- protip Run `git lfs prune` at times
-
- Resoruces
- [Official Tutorial](https://github.com/git-lfs/git-lfs/wiki/Tutorial)
-