Re: [PATCH 2/2] repack -ad: prune the list of shallow commits
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jul 17, 2018, 16:39 UTC
- Message-ID
- <CACsJy8Ce0kXTCzLf6jFq1QjY4Q4QePfk1JbgGUr-kQqQDCc7mA@mail.gmail.com>
- In-Reply-To
- <b4e01a963fd16f50d12c1f67c6e64bec8b1e9673.1531513093.git.gitgitgadget@gmail.com>
On Fri, Jul 13, 2018 at 10:19 PM Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote:
Show 21 quoted lines
> > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > 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> >
Could you elaborate a bit more? I don't quite see the connection between the reachability in the first two paragraphs and .git/shallow in the third one. I'm guessing we drop objects in between because "they go missing"? Where? How does prune_shallow() in prune.c play any role in this (if it does)?
-- Duy