On 08/18/2012 10:39 PM, Junio C Hamano wrote:
> mhag...@alum.mit.edu writes:
>> Given that a flag day would anyway be required to add a d/f-tolerant
>> system, I could live with a separate "graveyard" namespace as
>> originally proposed by Jeff.
>> However, I still think that as long as we are making a jump, we could
>> try to land closer to the ultimate destination.
> Do we _know_ already what the "ultimate destination" looks like?  

No; we can only guess.  I just wanted to submit some code so that the
existence/absence of code would not prejudice the decision.

> If the answer is yes, then I agree, but otherwise, I doubt it is a
> good idea to introduce unnecessary complexity to the system that may
> have to be ripped out and redone.
> I didn't get the impression that we know the "ultimate destination"
> from the previous discussion, especially if we discount the tangent
> around "having next and next/foo at the same time" which was on
> nobody's wish, but I may be misremembering things.

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.)

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

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

* 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.

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


Michael Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to