github.com/x-oss-byte/git-lfs@v2.5.2+incompatible/docs/man/git-lfs-prune.1.ronn (about) 1 git-lfs-prune(1) -- Delete old LFS files from local storage 2 =========================================================== 3 4 ## SYNOPSIS 5 6 `git lfs prune` [options] 7 8 ## DESCRIPTION 9 10 Deletes local copies of LFS files which are old, thus freeing up disk space. 11 Prune operates by enumerating all the locally stored objects, and then deleting 12 any which are not referenced by at least ONE of the following: 13 14 * the current checkout 15 * a 'recent branch'; see [RECENT FILES] 16 * a 'recent commit' on the current branch or recent branches; see [RECENT FILES] 17 * a commit which has not been pushed; see [UNPUSHED LFS FILES] 18 * any other worktree checkouts; see git-worktree(1) 19 20 In general terms, prune will delete files you're not currently using and which 21 are not 'recent', so long as they've been pushed i.e. the local copy is not the 22 only one. 23 24 The reflog is not considered, only commits. Therefore LFS objects that are 25 only referenced by orphaned commits are always deleted. 26 27 Note: you should not run `git lfs prune` if you have different repositories 28 sharing the same custom storage directory; see git-lfs-config(1) for more 29 details about `lfs.storage` option. 30 31 ## OPTIONS 32 33 * `--dry-run` `-d` 34 Don't actually delete anything, just report on what would have been done 35 36 * `--verify-remote` `-c` 37 Contact the remote and check that copies of the files we would delete 38 definitely exist before deleting. See [VERIFY REMOTE]. 39 40 * `--no-verify-remote` 41 Disables remote verification if lfs.pruneverifyremotealways was enabled in 42 settings. See [VERIFY REMOTE]. 43 44 * `--verbose` `-v` 45 Report the full detail of what is/would be deleted. 46 47 ## RECENT FILES 48 49 Prune won't delete LFS files referenced by 'recent' commits, in case you want 50 to use them again without having to download. The definition of 'recent' is 51 derived from the one used by git-lfs-fetch(1) to download recent objects with 52 the `--recent` option, with an offset of a number of days (default 3) to ensure 53 that we always keep files you download for a few days. 54 55 Here are the git-config(1) settings that control this behaviour: 56 57 * `lfs.pruneoffsetdays` <br> 58 The number of extra days added to the fetch recent settings when using them 59 to decide when to prune. So for a reference to be considered old enough to 60 prune, it has to be this many days older than the oldest reference that would 61 be downloaded via `git lfs fetch --recent`. Only used if the relevant 62 fetch recent 'days' setting is non-zero. Default 3 days. 63 64 * `lfs.fetchrecentrefsdays` <br> 65 `lfs.fetchrecentremoterefs` <br> 66 `lfs.fetchrecentcommitsdays` <br> 67 These have the same meaning as git-lfs-fetch(1) with the `--recent` option, 68 they are used as a base for the offset above. Anything which falls outside 69 of this offsetted window is considered old enough to prune. If a day value is 70 zero, that condition is not used at all to retain objects and they will be 71 pruned. 72 73 ## UNPUSHED LFS FILES 74 75 When the only copy of an LFS file is local, and it is still reachable from any 76 reference, that file can never be pruned, regardless of how old it is. 77 78 To determine whether an LFS file has been pushed, we check the difference 79 between local refs and remote refs; where the local ref is ahead, any LFS files 80 referenced in those commits is unpushed and will not be deleted. This works 81 because the LFS pre-push hook always ensures that LFS files are pushed before 82 the remote branch is updated. 83 84 See [DEFAULT REMOTE], for which remote is considered 'pushed' for pruning 85 purposes. 86 87 ## VERIFY REMOTE 88 89 The `--verify-remote` option calls the remote to ensure that any LFS files to be 90 deleted have copies on the remote before actually deleting them. 91 92 Usually the check performed by [UNPUSHED LFS FILES] is enough to determine that 93 files have been pushed, but if you want to be extra sure at the expense of extra 94 overhead you can make prune actually call the remote API and verify the 95 presence of the files you're about to delete locally. See [DEFAULT REMOTE] for 96 which remote is checked. 97 98 You can make this behaviour the default by setting `lfs.pruneverifyremotealways` 99 to true. 100 101 In addition to the overhead of calling the remote, using this option also 102 requires prune to distinguish between totally unreachable files (e.g. those that 103 were added to the index but never committed, or referenced only by orphaned 104 commits), and files which are still referenced, but by commits which are 105 prunable. This makes the prune process take longer. 106 107 ## DEFAULT REMOTE 108 109 When identifying [UNPUSHED LFS FILES] and performing [VERIFY REMOTE], a single 110 remote, 'origin', is normally used as the reference. This one remote is 111 considered canonical; even if you use multiple remotes, you probably want to 112 retain your local copies until they've made it to that remote. 'origin' is used 113 by default because that will usually be a master central repo, or your fork of 114 it - in both cases that's a valid remote backup of your work. If origin doesn't 115 exist then by default nothing will be pruned because everything is treated as 116 'unpushed'. 117 118 You can alter the remote via git config: `lfs.pruneremotetocheck`. Set this 119 to a different remote name to check that one instead of 'origin'. 120 121 ## SEE ALSO 122 123 git-lfs-fetch(1) 124 125 Part of the git-lfs(1) suite.