Re: Using trees for metatagging

From: martin f krafft <madduck@madduck.net>
Date: Feb 18, 2010, 22:53 UTC
Message-ID: <20100218225323.GK9756@lapse.rw.madduck.net>
In-Reply-To: <32541b131002181057gf27538ybf09dbf80b8dbce8@mail.gmail.com>

also sprach Avery Pennarun <apenwarr@gmail.com> [2010.02.19.0757 +1300]:

Show 8 quoted lines

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

The idea is obviously that you could merge ancestries and thus propagate all those changes.

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

It was a shortcut on my behalf. I meant that a new tree is written with the ref to the old blob removed and the ref to the new blob added.

Show 8 quoted lines

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

Right, this is the basis of merging. I understand all this. I suppose I didn't express myself clearly enough.

So I am trying to figure out:

1. how to create new trees for all trees that reference a blob that
   is superseeded by a new blob in some sort of scalable way;

2. how to maintain a separate ancestry of commits pointing to those
   trees in a way to be able to harness Git's merging capabilities.

Is this clearer?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"alle vorurteile kommen aus den eingeweiden."
                                                 - friedrich nietzsche
 
spamtraps: madduck.bogus@madduck.net