1GIT-LFS-PRUNE(1) GIT-LFS-PRUNE(1)
2
6 git-lfs-prune - Delete old LFS files from local storage
7
9 git lfs prune [options]
10
12 Deletes local copies of LFS files which are old, thus freeing up disk
13 space. Prune operates by enumerating all the locally stored objects,
14 and then deleting any which are not referenced by at least ONE of the
15 following:
16 • the current checkout
18 • all existing stashes
20 • a 'recent branch'; see RECENT FILES
22 • a 'recent commit' on the current branch or recent branches; see
24 RECENT FILES
25 • a commit which has not been pushed; see UNPUSHED LFS FILES
27 • any other worktree checkouts; see git-worktree(1)
29 In general terms, prune will delete files you’re not currently using
31 and which are not 'recent', so long as they’ve been pushed i.e. the
32 local copy is not the only one.
33 The reflog is not considered, only commits. Therefore LFS objects that
35 are only referenced by orphaned commits are always deleted.
36 Note: you should not run git lfs prune if you have different
38 repositories sharing the same custom storage directory; see
39 git-lfs-config(5) for more details about lfs.storage option.
40 In your Git configuration or in a .lfsconfig file, you may set
42 lfs.fetchexclude to a comma-separated list of paths. If
43 lfs.fetchexclude is defined, then any Git LFS files whose paths match
44 one in that list will be pruned unless they are referenced by a stash
45 or an unpushed commit. Paths are matched using wildcard matching as per
46 gitignore(5).
47
49 --dry-run, -d
50 Don’t actually delete anything, just report on what would have been
51 done
52 --force, -f
54 Prune all objects except unpushed objects, including objects
55 required for currently checked out refs. Implies --recent.
56 --recent
58 Prune even objects that would normally be preserved by the
59 configuration options specified below in RECENT FILES.
60 --verify-remote, -c
62 Contact the remote and check that copies of the files we would
63 delete definitely exist before deleting. See VERIFY REMOTE.
64 --no-verify-remote
66 Disables remote verification if lfs.pruneverifyremotealways was
67 enabled in settings. See VERIFY REMOTE.
68 --verbose, -v
70 Report the full detail of what is/would be deleted.
71
73 Prune won’t delete LFS files referenced by 'recent' commits, in case
74 you want to use them again without having to download. The definition
75 of 'recent' is derived from the one used by git-lfs-fetch(1) to
76 download recent objects with the --recent option, with an offset of a
77 number of days (default 3) to ensure that we always keep files you
78 download for a few days.
79 Here are the git-config(1) settings that control this behaviour:
81 • lfs.pruneoffsetdays The number of extra days added to the fetch
83 recent settings when using them to decide when to prune. So for a
84 reference to be considered old enough to prune, it has to be this
85 many days older than the oldest reference that would be downloaded
86 via git lfs fetch --recent. Only used if the relevant fetch recent
87 'days' setting is non-zero. Default 3 days.
88 • lfs.fetchrecentrefsdays lfs.fetchrecentremoterefs
90 lfs.fetchrecentcommitsdays These have the same meaning as
91 git-lfs-fetch(1) with the --recent option, they are used as a base
92 for the offset above. Anything which falls outside of this
93 offsetted window is considered old enough to prune. If a day value
94 is zero, that condition is not used at all to retain objects and
95 they will be pruned.
96
98 When the only copy of an LFS file is local, and it is still reachable
99 from any reference, that file can never be pruned, regardless of how
100 old it is.
101 To determine whether an LFS file has been pushed, we check the
103 difference between local refs and remote refs; where the local ref is
104 ahead, any LFS files referenced in those commits is unpushed and will
105 not be deleted. This works because the LFS pre-push hook always ensures
106 that LFS files are pushed before the remote branch is updated.
107 See DEFAULT REMOTE, for which remote is considered 'pushed' for pruning
109 purposes.
110
112 The --verify-remote option calls the remote to ensure that any LFS
113 files to be deleted have copies on the remote before actually deleting
114 them.
115 Usually the check performed by UNPUSHED LFS FILES is enough to
117 determine that files have been pushed, but if you want to be extra sure
118 at the expense of extra overhead you can make prune actually call the
119 remote API and verify the presence of the files you’re about to delete
120 locally. See DEFAULT REMOTE for which remote is checked.
121 You can make this behaviour the default by setting
123 lfs.pruneverifyremotealways to true.
124 In addition to the overhead of calling the remote, using this option
126 also requires prune to distinguish between totally unreachable files
127 (e.g. those that were added to the index but never committed, or
128 referenced only by orphaned commits), and files which are still
129 referenced, but by commits which are prunable. This makes the prune
130 process take longer.
131
133 When identifying UNPUSHED LFS FILES and performing VERIFY REMOTE, a
134 single remote, 'origin', is normally used as the reference. This one
135 remote is considered canonical; even if you use multiple remotes, you
136 probably want to retain your local copies until they’ve made it to that
137 remote. 'origin' is used by default because that will usually be a main
138 central repo, or your fork of it - in both cases that’s a valid remote
139 backup of your work. If origin doesn’t exist then by default nothing
140 will be pruned because everything is treated as 'unpushed'.
141 You can alter the remote via git config: lfs.pruneremotetocheck. Set
143 this to a different remote name to check that one instead of 'origin'.
144
146 git-lfs-fetch(1), gitignore(5).
147 Part of the git-lfs(1) suite.
149 GIT-LFS-PRUNE(1)