Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> 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.
--
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