Hi Duy, On Sun, 10 Jul 2016, Duy Nguyen wrote: > On Sun, Jul 10, 2016 at 12:59 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html