Re: Using trees for metatagging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



also sprach Avery Pennarun <apenwarr@xxxxxxxxx> [2010.02.19.0757 +1300]:
> > 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.

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

> 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@xxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]