Re: [PATCH 1/2] Delete ref $frotz by moving ref file to "deleted-$frotz~ref".

[Junio C Hamano <junkio@cox.net>]

Christian Couder <chriscool@tuxfamily.org> 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.