Well, I think there is an easy solution.
Just go back and say that when the user limits the size, it limits the
offset at which objects can *start*.
Not only is that the only thing that the index file itself cares about, it
also means that
- you don't ever need to undo anything at all (because you know the
starting offset) when you begin packing a new object.
This should simplify your patch a lot.
- the object size issue just goes away. Sure, the pack-file limit looks a
bit strange (it's no longer a hard limit on the *size* of the
pack-file, just on the object offsets), but let's face it, we really
really don't care.
And in practice, by setting the pack-file limit to 2GB (or even 1GB), you
never ever have to worry about the 32-bit filesystem limits any more,
unless your repository is fundamentally so screwed that you simply
*cannot* reporesent it well on something like FATFS (ie any object that is
2GB in size will probably have a blob that is even bigger, and FATFS
already has problems with it).
So in practice, just limiting the index offsets is what you really want
anyway.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
