Re: [PATCH] git-fast-import: note 1M limit of mark number

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Apr 16, 2008, 07:04 UTC
Message-ID: <4805A500.5070707@alum.mit.edu>
In-Reply-To: <48051882.8000201@vilain.net>

Sam Vilain wrote:

Show 16 quoted lines

> Michael Haggerty wrote:
>>> ++
>>> +Note that due to current internal limitations, you may not make marks
>>> +with a higher number than 1048575 (2^20-1).
>>>  
>>>  * A complete 40 byte or abbreviated commit SHA-1 in hex.
>>>  
>> Oh.  Um.  That is an awkwardly small number nowadays.
>>
>> cvs2svn has been used for repositories with O(2^20) distinct file
>> revisions (KDE, Mozilla, NetBSD, ...).  So this limit will likely be too
>> small for some users.
> 
> Right.  But, if you're not making the importer you write for a
> conversion of that size restartable, you're insane.  So, marking more
> than 1Mi *marks* in a single gfi session might not be so vital.

Well, call me insane then. Because there *are* no bulletproof incremental CVS importers, and it would be a lot of work to write one. (git-cvsimport doesn't count because it is far from bulletproof.) So it is reasonable to choose a high-quality one-time conversion over a broken restartable conversion.

Show 8 quoted lines

>> While I'm at it, let me also renew my suggestion that git-fast-import
>> use separate namespaces ("markspaces", so to speak) for file content
>> marks and for commit marks.  There is no reason for these distinct types
>> of marks to be located in a shared space of integers.
> 
> There is a reason, it's because they're both just object IDs.  Is it
> really that much of a drag?  I know what you mean though, it meant for
> my code I had to keep track of which type each mark was.

That's exactly my point. That's at least two of us then who have had extra work to merge two separate ID concepts into a single integer sequence. It's not a big deal, but it would be convenient if git-fast-import allowed the sequences to overlap.

Michael