Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > The idea is that moving: > > $GIT_DIR/refs/<refpath>/frotz > > to: > > $GIT_DIR/deleted-refs/<refpath>/frotz~ref > > maybe cheaper and safer than repacking the refs without the > deleted one. Before actually implementing delete_ref(), we discussed this "deleted-refs/" idea. but I do not think it is a direction we would want to go. Ref deletion is an operation that happens far far rarer than updates and lookups, and I deliberately chose to optimize for the latter. There are valid reasons to delete refs, and one most frequent one would be to discard throw-away temporary branches you may have needed to switch to when your work was interrupted. But even counting that kind of deletion, I imagine that you would not be creating and removing more than one branch per every 10 commits you would create, and I also imagine you would be invoking not less than 5 operations that inspect project history, such as git-log and git-diff, between commits you make. An operation to build a new commit itself needs at least two lookups (one to see what's current upfront, and another to see nobody touched it upon lockless update). Most history-related operations at least need to look at one (typically, HEAD), and any refname you use to spell the name of an object or revision range (e.g. "v2.6.17..v2.6.18~10" needs to look at tags/v2.6.17 and tags/v2.6.18). Optimizing for deletion path at the expense of giving even a tiny penalty to lookup path is optimizing for a wrong case, and that is why I rejected deleted-refs/ idea when I originally did the delete_ref() implementation. Having said that, I would definitely think there still are rooms for optimization in the current implementation. For example, I do not recall offhand if I made the code to unconditionally repack without the deleted one, or only repack when we know the ref being deleted exists in the packed refs file. The latter obviously would be more efficient and if we currently do not do that, making it do so is a very welcomed change. Especially, given that the latest code does not pack branch heads by default, when a temporary throw-away branch is discarded, it is far more likely that it is not packed and we do not need to repack. Independent from this topic of "removing deleted from packed" vs "using deleted-refs/", I think we still do not handle .git/logs/ hierarchy correctly in the current code when ref deletion is involved. We already made it to correctly unlink/rmdir/mkdir on-demand for .git/refs/ hierarchy and I think we need to have code that parallels that for the .git/logs/ side. - 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