Junio C Hamano wrote:
> Linus Torvalds <torvalds@xxxxxxxx> writes:
>
>> 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 ;)
>
> For this particular one, there is no need for version 2.
Actually, I think it is both true and untrue. True, because we need some
indicator that we trust packed-refs file to provide tag dereferences to
distinguish between the case when there are no tag objects at all, so there
are no tag dereferences in packed-refs, and the situation where we use
packed-refs generated by older git, and there are no tag dereferences in
packed-refs because git didn't saved it.
Untrue, because it is not enough. In the case[*1*] when packed-refs was
created with tag dereferences, then some "heavyweight" tags were added
by older version of git (adding references doesn't rewrite packed-refs
if I understand correctly), then we use new git again and trust that there
are no derefs...
[*1*] For example when git repository is on the network filesystem, but
programs are installed locally, and perhaps computers in the network are
heterogenic (perhaps even different architectures: PC vs. Sun and/or
different operating systems: Linux vs. FreeBSD vs. Solaris vs.
Windows+Cygwin) and have different versions of git installed (perhaps
one of them is "your" machine, where you have admin rights, and you have
newest git installed there). Or for example using git repository on USB
stick, again on different computers with different version of git installed.
---------------------------------------------------------------------
To summarize, we have the following proposals of the packed-refs format
extension
The unusable Linux Torvalds proposal (unusable because of requiring
newer packed-refs work with older git, for example in the case [*1*]
or the case of git downgrade):
lt> <sha1><space><name>[<space><sha1-of-deref>]*
Linus Torvalds "Now somebody would just need to implement that ;)"
proposal:
lt> <sha1> refs/tags/tagname
lt> ^<sha1-unpeeled>
lt> ^<sha1-unpeeled-of-unpeeled>
lt> ...
lt> <sha1> refs/tags/othertag
Junio C Hamano proposal _with code_ (proposal with code usually wins).
Less elegant IMVHO, but perhaps better.
jc> My current wip does:
jc>
jc> SHA-1 SP name LF
jc> SHA-1 SP SP name^{} LF
jc>
jc> the latter of which is ignored by code in the wild and the new
jc> code can take advantage of (and fall back the usual deref_tag
jc> when it is not available).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
-
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