Sam Vilain wrote:
> The insert_mark() function in fast-import.c has this limit; note the
> limitation in the documentation.
>
> Signed-off-by: Sam Vilain <sam@xxxxxxxxxx>
> ---
> 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
--
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
