On Sun, 19 Nov 2006, 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.
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
-
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