also sprach Jeff King <peff@xxxxxxxx> [2011.08.02.2051 +0200]: > I agree that is an annoyance, but it is one we can deal with. In the > near term, I wonder if a "tg clone" would be appropriate to add the > extra fetch refspecs when cloning (or even a "tg init" inside an > existing git repo -- I don't actually use topgit, so I'm not sure what > the usual initialization process, if any, is). Hey Jeff, thanks for your response. TopGit does come with these commands to do the setup for you, but that does not ensure that a new contributor without any idea about TopGit won't forget to run them. The argument against tg-clone is mainly that I really do not want to encapsulate/abstract functionality, but rather stay as close as possible to pure Git, and never to mandate anyone to use anything else. > In the longer term, it might be nice if git was better at sharing > third-party refs. The problem is that we don't know what the refs > mean, so we don't know which ones are appropriate for sharing. > Maybe we could do something like "refs/shared/topgit/*", and git > by default would push and pull items under refs/shared? This could be an interesting and viable approach. > > Therefore I thought it would be sensible to store these data in > > commit. When the data change, there will always be a new commit to > > store these data, and we do *not* want to update the data in > > previous commits. Finding the data then becomes backtracking the > > branch history until a commit is found containing them. > > That seems to me like you are sticking information in a commit that is > not actually about the commit, but about the ref that happens to point > to the commit. What if I have two refs that point to the same commit, > but with two different topgit bases? I don't think this can happen, but the point is valid. > What about years later, when that information isn't interesting > anymore? You're still carrying the cruft inside your commit > objects. […] > I'm still not 100% convinced you want per-commit storage, though, > and not per-ref storage. Yes, I do want per-ref storage. Your arguments against my orphan parent pointer approach (which could later be a x-*-ref approach) are valid. It just seems to me that per-ref storage is a lot further away than per-commit storage, and I'd really like to move forward with TopGit… Thank you, -- martin | http://madduck.net/ | http://two.sentenc.es/ "one should never trust a woman who tells her real age. if she tells that, she will tell anything." -- oscar wilde spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)