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
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
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
