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

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

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

Show 28 quoted lines

> On Sat, 21 Apr 2007, Junio C Hamano wrote:
>
>> This is on top of 'next' I'll push out after I am done with
>> v1.5.1.2 I am preparing today.
>> 
>> [1/2] Add 'filter' attribute and external filter driver definition.
>> [2/2] Add 'ident' conversion.
>
> I think this is great work! And it is useful, too. Let me describe a usage 
> scenario I have in mind.
>
> Being stuck with Pine, which still does not do Maildir, and wanting 
> to be able to read my mails as distributed as I am working on documents 
> and software projects, I always dreamt of having all my mail in Git.
>
> With filters, it should be relatively easy to do that. Before checking in, 
> the individual mailbox files are split, the contents are put into the 
> object database, and the mailbox file is replaced by a text file 
> consisting of the SHA1s of the mails.
>
> Ideally, I would eventually not only teach Pine to understand Maildir 
> format, but read and store the mails in a Git backend. Alas, I am way too 
> lazy for that.
>
> So, with filters I'd do the cheap and easy thing.
>
> You may not be able to appreciate the advantages of my scenario, but this 
> kind of flexibility is what makes Git so useful.

An earlier message $gmane/44896 from Linus comes to my mind.  An excerpt:

   The thing is, it's easy enough (although potentially _very_ expensive) to 
   run some per-file script at each commit and at each checkout. But there 
   are some fundamental operations that are even more common:

    - checking for "file changed", aka the "git status" kind of thing

      Anything we do would have to follow the same "stat" rules, at a 
      minimum. You can *not* afford to have to check the file manually.

      So especially if you combine several pieces into one, or split one file 
      into several pieces, your index would have to contain the entry 
      that matches the _filesystem_ (because that's what the index is all 
      about), but then the *tree* would contain the pieces (or the single 
      entry that matches several filesystem entries).

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

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.