Re: [PATCH 2/2] repack -ad: prune the list of shallow commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 17 Jul 2018, Duy Nguyen wrote:

> On Tue, Jul 17, 2018 at 6:39 PM Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> >
> > On Fri, Jul 13, 2018 at 10:19 PM Johannes Schindelin via GitGitGadget
> > <gitgitgadget@xxxxxxxxx> wrote:
> > >
> > > From: Johannes Schindelin <johannes.schindelin@xxxxxx>
> > >
> > > 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux