git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: [WISH] Store also tag dereferences in packed-refs
Date: Mon, 20 Nov 2006 10:40:15 +0100	[thread overview]
Message-ID: <ejrt37$fg9$1@sea.gmane.org> (raw)
In-Reply-To: 7vr6vy7smi.fsf@assigned-by-dhcp.cox.net

Junio C Hamano wrote:

> Linus Torvalds <torvalds@osdl.org> 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


  reply	other threads:[~2006-11-20  9:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-18  9:15 [WISH] Store also tag dereferences in packed-refs Marco Costalba
2006-11-18 18:38 ` Junio C Hamano
2006-11-18 18:43   ` Petr Baudis
2006-11-18 18:47     ` Marco Costalba
2006-11-18 19:04       ` Junio C Hamano
2006-11-19  0:28         ` Marco Costalba
2006-11-19  1:11           ` Linus Torvalds
2006-11-19  1:40             ` Junio C Hamano
2006-11-19  1:45               ` Junio C Hamano
2006-11-19  1:59                 ` Linus Torvalds
2006-11-19  9:40             ` Marco Costalba
2006-11-19 18:05               ` Linus Torvalds
2006-11-19 19:07                 ` Marco Costalba
2006-11-19 20:09                   ` Marco Costalba
2006-11-19 20:36                     ` Linus Torvalds
2006-11-19 20:44                       ` Linus Torvalds
2006-11-19 21:01                       ` Junio C Hamano
2006-11-19 21:14                         ` Linus Torvalds
2006-11-19 21:24                           ` Jakub Narebski
2006-11-19 23:36                             ` Linus Torvalds
2006-11-20  2:35                               ` Junio C Hamano
2006-11-20  9:40                                 ` Jakub Narebski [this message]
2006-11-20 12:56                                   ` Marco Costalba
2006-11-20 16:29                                 ` Linus Torvalds
2006-11-20 19:32                                   ` Junio C Hamano
2006-11-19 22:25                       ` Marco Costalba
2006-11-19 23:26                         ` Linus Torvalds
2006-11-19 20:18                   ` Linus Torvalds
     [not found] ` <200611201154.08732.jnareb@gmail.com>
     [not found]   ` <7vu00u2wln.fsf@assigned-by-dhcp.cox.net>
2006-11-20 11:33     ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ejrt37$fg9$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).