Re: metastore (was: Track /etc directory using Git)

> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.15.1610 +0200]:
>> No.  Git is a source code management system.  Everything else that
>> you can do with it is a bonus, a second class citizen.  Should we
>> really try to support your use case, we will invariably affect the
>> primary use case.
>
> I thought git was primarily a content tracker... so it all comes
> down to how to define content, doesn't it? But either way, we need
> not discuss that because that definition depends a lot on context
> and purpose and thus cannot be answered once and for all.
>
> I understand that for the primary use case, tracking nothing more
> than +x makes sense and should not be interfered with. This is why
> I was proposing a policy-based approach. The primary use case is
> unaffected, it's the default policy. Someone may choose to track
> other mode bits or file/inode attributes, according to one of
> several policies available with git, or even a custom policy. In
> that case, the repository needs to be appropriately configured.
>
> The reason why I say this should be done inside git rather than with
> hooks and an external tool, such as metastore is quite simple: git
> knows about every content entity in any tree of a repo and already
> has a data node for each object. Rather than introducing a parallel
> object database (shadow hierarchy or single file), it would make
> a lot more sense and be way more robust to attach additional
> information to these object nodes, wouldn't it?
>
> So with "appropriately configured" above, I meant that one should be
> able to say
>
>  git-config core.track all
>
> or
>
>  git-config core.track mode+attr
>
> or the default:
>
>  git-config core.track 7666
>  (read that as a umask, which masks out everything but the three
>  x bits. I made it 7666 instead of 7677 because core.umask and
>  core.sharedrepository then override the group and world bits if
>  needed)
>
> and have git do the right thing, rather than expecting those who
> want to track more than the executable bit to assemble a brittle set
> of hooks and metadata collectors+applicators and hope it all works.
>
> I understand also that this is not top priority for git, which is
> why I said earlier in the thread that the real difficulty might be
> to get Junio to accept a patch. But I think that the patch would be
> rather contained and small, having it all configurable would make it
> unintrusive, and if we all test it real well, it should pass as
> a bonus. After all, git can e.g upload patches to IMAP boxes, which
> in my world clearly is bonus material as well.