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". For instance you want some sort of representation for "the set of files that need review". You /could/ create a new tree and reference all files in that set as children. Now if you wanted to find out what to review, you'd list the children of this tree. After reviewing a file, you write a new tree with the set less that file's ref.. Obviously, if you made changes to the file, it should be reconnected to all other trees that referenced it. I have a couple of questions about this: 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. 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? 3. Am I right in assuming that I'd have to track a completely seperate ancestry for this tree, that is create e.g. a commit object, point refs/metatrees/mytree to it, and reference the tree from the commit? 4. Since this hierarchy is not really to be mapped into the filesystem, how would one resolve conflicts when merging ancestries? Of course it would be nice if I could check out this meta tree into the filesystem, make changes, and be assured that new blobs replace old blobs in other referencing trees, as per (2.), but that's a pipedream maybe. 5. Do you know of similar efforts? Are there must-reads out there, apart from the design of Git? Thank you, -- martin | http://madduck.net/ | http://two.sentenc.es/ kill ugly radio -- frank zappa spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)