On Tue, Jul 17, 2018 at 9:51 AM Johannes Schindelin via GitGitGadget <gitgitgad...@gmail.com> wrote: > While it is true that we never add unreachable commits into pack files > intentionally (as `git repack`'s documentation states), we must not > forget that a `git fetch --prune` (or even a `git fetch` when a ref was > force-pushed in the meantime) can make a commit unreachable that was > reachable before. > > Therefore it is not safe to assume that a `git repack -adlf` will keep > unreachable commits alone (under the assumption that they had not been > packed in the first place). > > This is particularly important to keep in mind when looking at the > `.git/shallow` file: if any commits listed in that file become > unreachable, it is not a problem, but if they go missing, it *is* a > problem. One symptom of this problem is that a deepening fetch may now > fail with > > fatal: error in object: unshallow <commit-hash> > > To avoid this problem, let's prune the shallow list in `git repack` when > the `-d` option is passed, unless `-A` is passed, too (which would force > the now-unreachable objects to be turned into loose objects instead of > being deleted). Additionally, e also need to take `--keep-reachable` and
s/, e/, we/ > `--unpack-unreachable=<date>` into account. > > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de>
