Re: [PATCH] git-fast-import: note 1M limit of mark number
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Apr 15, 2008, 15:50 UTC
- Message-ID
- <4804CECE.2040205@alum.mit.edu>
- In-Reply-To
- <20080415125222.C55C121CE8F@mail.utsl.gen.nz>
Sam Vilain wrote:
Show 22 quoted lines
> The insert_mark() function in fast-import.c has this limit; note the > limitation in the documentation. > > Signed-off-by: Sam Vilain <sam@vilain.net> > --- > Documentation/git-fast-import.txt | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt > index c29a4f8..b5cc3c2 100644 > --- a/Documentation/git-fast-import.txt > +++ b/Documentation/git-fast-import.txt > @@ -410,6 +410,9 @@ or `refs/heads/42`), or an abbreviated SHA-1 which happened to > consist only of base-10 digits. > + > Marks must be declared (via `mark`) before they can be used. > ++ > +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.
Moreover, cvs2git needs to generate marks for both file contents and for commits. It generates the latter by adding 1000000000 to the small integer IDs that it uses internally. If git-fast-import only allows 20-bit integers, this makes me wonder why this hasn't broken dramatically in the past. Pure numerological good fortune, combined with weak range checking in git-fast-import?
In any case, this restriction will require changes in cvs2git.
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.
Michael