Shawn Pearce <spearce@xxxxxxxxxxx> writes: > I've been thinking about implementing ref storage within a Git tree > object. Just store the commit/tag/object IDs in a tree (or graph > of trees) with a mode of '0'. Anchor that under '.git/refs-tree'. > Any edit of a ref would "lock" .git/refs-tree, create a new tree > containing the update, then replace .git/refs-tree. > > But it would put additional stress on the objects directory by > creating a lot of trees which would never get pulled into pack > files and thus would need to be pruned away on a regular basis. I do not see any advantage of making such a phoney object at all, but I do agree that the current one file per ref can be less than optimal when your repository has tons of tags or refs. We've designed the ref interface well enough so that only very narrow core functions know the implementation (and properly written Porcelain would access refs via update-ref and symbolic-ref interfaces), so the impact of changing the one-file-per-ref implementation to something based on a single simple databasy file (e.g. gdbm, bdb, sqlite, ...) would be reasonably limited. - 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