Hi, On Sat, 9 Jun 2007, Daniel Barkalow wrote: > 1) It's probably best to use some new types, rather than trees and > commits. This gives you more flexibility to structure things in ways > that exactly fit what's going on, which is one of the main reasons git > is so good for version control. I fail to see why this has to be a new type. The flexibility in Git lies IMHO therein that it does _not_ have a plethora of objects. Rather, there are just 4 object types, which serve their purpose well, indeed. (I would even have argued that tag objects could have been simple commit objects, with an additional header "tag", but oh well.) I suspect that you want to introduce a different object type to be able to implement a new algorithm. But I think that the appropriate data structure is still contained in the existing set of types in Git. > 2) It's probably best to have the history be per-bug, with each revision > being an update to that report, and have the complete database be a > refs/ subdirectory. I don't think that this is a good solution: >From the implementation view point, a lot of branches sucks performance-wise. Especially since we do not pack branch refs. Side note: I recently kicked around the idea to actually keep the refs in the packed-refs file, and for updating refs do a lock-mmap-findref-replace-or-rewrite, where a rewrite only happens if we delete or insert a ref. Then, we could even unify the info/refs and packed-refs, so that we don't hear bugreports about http transport not working every week or so. Just an idea. Ciao, Dscho - 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
