Re: [WISH] Store also tag dereferences in packed-refs

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 20, 2006, 16:29 UTC
Message-ID: <Pine.LNX.4.64.0611200817330.3692@woody.osdl.org>
In-Reply-To: <7vr6vy7smi.fsf@assigned-by-dhcp.cox.net>

On Sun, 19 Nov 2006, Junio C Hamano wrote:

Show 13 quoted lines

> 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.

I don't think you understand.

> My current wip does:
> 
> 	SHA-1 SP name LF
> 	SHA-1 SP SP name^{} LF

I think that's ugly and redundant (if "name" is ever different from the lien above it, that would be a bug), but that's not the real problem.

The real problem is (go back to the mail that you answered, and snipped the explanation from) this:

 - you have a thousand tags

 - NONE of them are "tag objects".

 - as a result your ref-pack file doesn't have a _single_ of the ^{} lines

Think about it. How do you know whether you should look up the tag objects for "-d" or not?

The answer is: you don't. You can't tell a "version 1" and "version 2" file apart. It might be an old "version 1" file that simply doesn't _have_ dereference information. Or it might be a "version 2" file that _does_ have dereference information, but nothing to dereference.

So you either have to:

 - look up each object again to see if it's a tag that should be 
   dereferenced

OR:

 - add a "# ref-pack version 2" flag at the top of the file.

So it's not about "parsing" the new file structure. I realize that parsing it is trivial. It's simply about knowing whether the new information _could_ be there or not.

And once you have that flag, your _future_ extensions can add their own version, which is an added bonus. But that means that "version 2" parsing should _also_ ignore lines that it cannot match, so you'd better have an escape from the new format. I personally think that using

	^<sha1><lf>

instead of "<sha1><space><space><name>^{}<lf>" is better partly for that reason: it's not only denser, it is "stricter" in the sense that there's less room for some future extended version that could be mistaken for a "version 2 unpeeling" line.

(But you can do the same thing with your version too. You should:
 - check that there is just _one_ extra space
 - verify that the name matches the previous one
 - verify that it ends exactly with "^{}", so that any future extension 
   could add their own flags at the end.)

But regardless of which format chosen, you need the flag of "this format is in use", exactly because the extended unpeeling information might not _exist_.

Oh, and regardless of which format chosen, you'd need to verify that the unpeeled object in the pack wasn't overridden, of course.

		Linus