On Thu, 5 Apr 2007, Nicolas Pitre wrote: > > > (2) Pack the object any way and let the packfile size exceed > > my specification. Ignoring a clear preference from the user > > doesn't seem good. > > It is not indeed. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html