Re: [PATCH 2/2] repack -ad: prune the list of shallow commits
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 19, 2018, 17:50 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1807191949150.71@tvgsbejvaqbjf.bet>
- In-Reply-To
- <CACsJy8Cxp6Gtt3YdWvQ0=t4vqBAqNxrGPeY4B7mtjsiLNpG5TQ@mail.gmail.com>
Hi,
On Tue, 17 Jul 2018, Duy Nguyen wrote:
Show 32 quoted lines
> On Tue, Jul 17, 2018 at 6:39 PM Duy Nguyen <pclouds@gmail.com> wrote: > > > > On Fri, Jul 13, 2018 at 10:19 PM Johannes Schindelin via GitGitGadget > > <gitgitgadget@gmail.com> wrote: > > > > > > 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? > > Never mind. The problem is described in another patch.. sigh.. I > understand you want to flip that "failure" to "success" but personally > I don't think it worth it to look back in history and have "what?" > moments like when I read this patch alone.
The split was not meant for your benefit, but for the benefit of verifying that I indeed fixed a problem.
I don't think it is a wise idea to squash them together.
Ciao, Dscho