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". -- Duy -- 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