Re: gc and repack ignore .git/*HEAD when checking reachability

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 10, 2016, 14:16 UTC
Message-ID: <alpine.DEB.2.20.1607101602320.6426@virtualbox>
In-Reply-To: <CACsJy8BWKrXqXnbEgSKJ9gKcAyvdZhExfgh5zBRisX8R3BkBLw@mail.gmail.com>

Hi Duy,

On Sun, 10 Jul 2016, Duy Nguyen wrote:

Show 34 quoted lines

> On Sun, Jul 10, 2016 at 12:59 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >> >> Now, how about special-casing *just* these legacy files in gc: HEAD,
> >> >> FETCH_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD? Any new transient refs should
> >> >> live in the refs/ namespace, which is already handled.
> >> >
> >> > That seems workable as well; in that case, we should also document this
> >> > (in the git-gc manpage at a minimum), and explicitly suggest creating
> >> > refs in refs/ but outside of refs/heads/ and refs/tags/, rather than
> >> > directly in .git/.
> >>
> >> Not just outside refs/heads and refs/tags. It has to be in a specified
> >> namespace like refs/worktree/ or something (we are close to be ready
> >> for that). We could update the man page about git-gc shortcomings now,
> >> but I think we should wait until refs/worktree (or something like
> >> that) becomes true before suggesting more.
> >
> > We have a precedent for a ref that is directly underneath refs/:
> > refs/stash.
> >
> > IMO that is okay: depending on the use case, we would need multiple refs
> > (like refs/notes/*) or a single ref (like refs/stash).
> >
> > The important part is that the new refs start with refs/, and if they are
> > to be transient, start neither with refs/heads/ nor with refs/tags/.
> 
> No, the point is, refs subsystem needs to know which refs is per-repo,
> which is per-worktree. So far the rules are  "everything under refs,
> except a few known exceptions, is per-repo" and "everything directly
> under $GIT_DIR is per-worktree", which work fine. But if you allow to
> move per-worktree to "refs" freely, then the "known exceptions" will
> have to be updated every time a new per-worktree ref appears. It'll be
> easier to modify the first rule as "everything under refs, except some
> legacy exceptions and refs/worktree, is per-repo".

Given the substantial pain and suffering I have due to per-worktree reflogs (and those are *just* HEAD's reflogs!), it appears to me that per-worktree refs would be a particularly poor feature.

I agree that HEAD needs to be per-worktree, but already the fact that the HEADs of the worktrees, along with their reflogs, are *not* visible to all other worktrees causes substantial trouble.

In my mind, a much more natural design would have been to map transparently each worktree's HEAD to refs/worktree/<name>/HEAD *and keep those refs and reflogs visible across all worktrees*.

With that design, I would not have irretrievably lost reflogs to auto-gc nor dozens of hours trying to figure out how to have *any* auto-gc succeed again (because I need to reduce the horrible slowness incurred by too many loose objects). My interactive rebases would also not have started to print the auto-gc error after every friggin' pick.

Ciao, Dscho