On Mon, May 20, 2013 at 8:28 PM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> I wasn't considering disallowing _anything_, rather open up to the
>> idea that a tree object might refer to tag objects as well as
>> commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted
>> scheme,
Johan Herland writes:
> I wasn't considering disallowing _anything_, rather open up to the
> idea that a tree object might refer to tag objects as well as
> commits/trees/blobs. E.g. in my suggested-but-pretty-much-retracted
> scheme, I was considering whether the tree entry at the "virtual" path
On Mon, May 20, 2013 at 7:21 PM, Junio C Hamano wrote:
> Johan Herland writes:
>
>>> Of course in either case we couldn't use a tree object directly, because
>>> these new "reference tree" objects would refer not only to blobs and
>>> other trees but also to commits and tags.
>>
>> Indeed. I don'
Johan Herland writes:
>> Of course in either case we couldn't use a tree object directly, because
>> these new "reference tree" objects would refer not only to blobs and
>> other trees but also to commits and tags.
>
> Indeed. I don't know if the best solution would be to actually _allow_
> that
On Mon, May 20, 2013 at 2:15 PM, Michael Haggerty wrote:
> This is a very interesting idea. "It's turtles all the way down."
:)
> On 05/20/2013 12:28 PM, Johan Herland wrote:
>> For server-class installations we need ref storage that can be read
>> (and updated?) atomically, and the current sys
5 matches
Mail list logo
