

lfs.pruneoffsetdays The number of extra days added to the fetch recent settings when using them to decide when to prune.Here are the git-config(1) settings that control this behaviour: The definition of 'recent' is derived from the one used by git-lfs-fetch(1) to download recent objects with the -recent option, with an offset of a number of days (default 3) to ensure that we always keep files you download for a few days. Prune won’t delete LFS files referenced by 'recent' commits, in case you want to use them again without having to download.
#GIT DELETE ALL NEW FILES FULL#
Report the full detail of what is/would be deleted.
#GIT DELETE ALL NEW FILES VERIFICATION#
no-verify-remoteĭisables remote verification if lfs.pruneverifyremotealways was enabled in settings. verify-remote, -cĬontact the remote and check that copies of the files we would delete definitely exist before deleting. Prune even objects that would normally be preserved by the configuration options specified below in Recent Files. Prune all objects except unpushed objects, including objects required for currently checked out refs. Options -dry-run, -dĭon’t actually delete anything, just report on what would have been done -force, -f Paths are matched using wildcard matching as per gitignore(5). If lfs.fetchexclude is defined, then any Git LFS files whose paths match one in that list will be pruned unless they are referenced by a stash or an unpushed commit. lfsconfig file, you may set lfs.fetchexclude to a comma-separated list of paths. Note: you should not run git lfs prune if you have different repositories sharing the same custom storage directory see git-lfs-config(5) for more details about lfs.storage option. Therefore LFS objects that are only referenced by orphaned commits are always deleted. The reflog is not considered, only commits. In general terms, prune will delete files you’re not currently using and which are not 'recent', so long as they’ve been pushed i.e. any other worktree checkouts see git-worktree(1).

