Re: [PATCH 0/2] Controversial blob munging series

From: Junio C Hamano <junkio@cox.net>
Date: Apr 23, 2007, 18:42 UTC
Message-ID: <7virbnexuc.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0704231933560.8822@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 13 quoted lines

> On Mon, 23 Apr 2007, Junio C Hamano wrote:
> ...
>> ... I am inclined to think that this is quite fundamental.  I
>> think you just fell into category who want "extended semantics"
>> Linus talked about in $gmane/45214:
>> 
>>   I suspect that this gets some complaining off our back, but I *also* 
>>   suspect that people will actually end up really screwing themselves with 
>>   something like this and then blaming us and causing a huge pain down the 
>>   line when we've supported this and people want "extended semantics" that 
>>   are no longer clean.
>> 
>> which is kind of dissapointing.

I think this was the biggest worry. If even Dscho, who is among a dozen people with the most intimate knowledge of git on the planet, gets it wrong, I can almost guarantee that we will get into the mess Linus predicted above.

Show 8 quoted lines

>> Even if you somehow solved the issue of "stat" rule, I do not
>> know what your plans are to manage the blobs that you drop in
>> the object store.  The list of object names in the mail-index
>> file you are generating do not count as connectivity for the
>> purpose of fetch/push/fsck/prune.
>
> I had the idea to update a ref, which holds "trees" of message-id -> blob 
> pairs, and get updated at the same time.

I somehow thought this mailbox thing was because you wanted to transfer mailboxes across repositories. How would you prevent that ref from getting out of sync with the mail-index file git knows nothing about its involvement in connectivity?