On Sun, 19 Nov 2006, Jakub Narebski wrote: > > So the only reason against this format (IMHO more reasonable, more readable > and more readable, and even easy extendable to the whole chain of derefs) > is code in the wild? > > By the way, do we copy packed refs literaly when fetching or cloning? The packed refs format is _purely_ a local format. So in that sense, we can change it any way we want, and nobody really cares. HOWEVER, even on a local machine, we generally want to be able to upgrade and downgrade git versions without having to worry about things like this, and having to convert one format to another. So using a format that "just works" with any version of git that understands packed refs is _wildly_ more preferable over changing the format. Btw, the simplest and best format is probably to make the new extension look something like 8ba130df4b67fa40878ccf80d54615132d24bc68 refs/tags/v2.6.17 ^427abfa28afedffadfca9dd8b067eb6d36bac53f d882e0c80e6e3c60640492b83395e6fbbae04276 refs/tags/v2.6.17-rc1 ^6246b6128bbe34d0752f119cf7c5111c85fe481d which is basically almost as dense as having a space on the same line, and will also trigger the old "that's not a valid line, just ignore it" reaction from older versions. So the parsing rules for that would simply be: - if you see a line that starts with a "^<sha1>", then that is the "unpeeling" of the previous packed entry (which in turn might have been an unpeeling itself) So if you were to have tags pointing to tags, you migt have <sha1> refs/tags/tagname ^<sha1-unpeeled> ^<sha1-unpeeled-of-unpeeled> ... <sha1> refs/tags/othertag In addition, we'd need a line at the top of the file that says "this has unpeeled information", because otherwise we have no way to distinguish between the case of "no actual tag objects" and "old-fashioned ref-pack file without any unpeeling info" - since they'd look identical. So I'd suggest adding - at the very top of the ref-pack file - a line line # Ref-pack version 2 which will be ignored by the current ref-pack reader (again, because it's not a valid ref line), but we can use it in the future to specify further extensions if we want to. Now somebody would just need to implement that ;) Linus - 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