Re: Using trees for metatagging

From: Avery Pennarun <apenwarr@gmail.com>
Date: Feb 18, 2010, 18:57 UTC
Message-ID: <32541b131002181057gf27538ybf09dbf80b8dbce8@mail.gmail.com>
In-Reply-To: <20100218041240.GA4127@lapse.rw.madduck.net>

On Wed, Feb 17, 2010 at 11:12 PM, martin f krafft <madduck@madduck.net> wrote:

> Git's object store uses trees mainly to represent a hierarchical
> filesystem. It occurs to me that you could layer additional
> hierarchies on top — specifically, you could use it to track subsets
> of files, i.e. "tagging".

I think what you *really* want here is to create a branch containing a single file, which is the list of all the files you want to review. Then when you're done reviewing a file, delete it from your list and commit it. Then just check out that file list branch in another clone of your repository and manipulate it however you like.

Sorry to be boring.

> 1. Does Git provide plumbing for me to find out which trees
>   reference a given blob? If not, I will have to iterate all trees
>   and record which ones have a given message as a child.

No, you will have to iterate. Also, if *other* people have trees referencing that blob in *their* repositories, you won't know, so you can never be sure that you've successfully found all objects in the universe that refer to a particular blob.

Show 5 quoted lines

> 2. Is there a way you can fathom by which unlinking a blob from the
>   main hierarchy also causes it to be unlinked from this meta tree
>   I am speaking of as well? Similarly, if a blob is rewritten, how
>   could I make sure it replaces the old blob in all referencing
>   trees?

blobs cannot replace other blobs. And a tree that contains a particular blob (indexed by sha1) will never *not* contain that blob, because the identity of that tree is based on the identitity of the blobs it contains. You can create a new tree that doesn't contain the blob, but the commit that contained the old tree will never contain the new tree. You would have to create a new commit that contains the new tree, but any commits based on your old commit will never be based on your new commit. And so on.

That's just the way content-addressed storage works. Sounds like you need to read more about it.

Have fun,

Avery