Re: [RFC 0/3] Reflogs for deleted refs: fix breakage and suggest namespace change

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2012, 16:27 UTC
Message-ID: <7vlihaq22v.fsf@alter.siamese.dyndns.org>
In-Reply-To: <5030E7D6.8020206@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 9 quoted lines

> It's been a wish of mine, but it's pretty low priority.  I've also
> brainstormed about some other changes that could be connected with a new
> repo format:
>
> * Allow "deleted" loose references (for example denoted by value 0{40})
> that override packed references with the same name.  This would remove
> the need to rewrite the packed-refs file when a reference is deleted.
> (A prerequisite for this change would be to allow next and next/foo at
> the same time.)

We would need to think the performance implications through of the approach; it tempts us to accumulate the loose "removed" markers in the hope that it would be an improvement than having to rewrite the packed-refs over and over, and without numbers to back that theory up, we may be worsening the system without knowing.

Having said that, it is an interesting idea. I wouldn't use 0{40} as the sentinel value but rather use letters outside [0-9a-f], though.

> * Push HEAD and its friends down out of $GIT_DIR into a
> reference-specific directory.

Not going to happen for several years, I am afraid, as I think many casual tools do an equivalent of "test -f $DIR/HEAD" to see if $DIR is a repository; even our own gitweb does so.

We should advertise an easy way for scripted Porcelains to directly ask is_git_directory().

> * Rename lock files to look less like reference names (e.g., something
> like "refs/foo~lock" instead of "refs/foo.lock").

If you do the ~d/~f thing, foo.lock becomes a non-issue, no?

> * Somehow munge reference names in a way to avoid other filesystem
> limitations -- e.g., case insensitivity, filenames like "com" and "prn"
> or with multiple dots under Windows.

Very interesting. I however am afraid that the users and the projects will learn to avoid the problematic names a lot sooner than such a change will be implemented to make the issue go away (or they have already learned long time ago), and the end result may end up solving a non-issue only to make the output from "find .git/refs" even more unreadable.

> * ...or maybe a packed-refs file that can (usually) be updated in-place,
> and get rid of loose references entirely.

I find this equally intriguing as your "deleted" one above.