fast-import should fail on invalid unsupported paths

Hi,

with this simple recipe, you get a non-usable repository:

mkdir foo cd foo git init --bare repo cd repo git fast-import <<"EOM" commit refs/heads/master committer <foo@bar.baz> 0 +0000 data 3 foo M 644 inline foo/.git/bar data 3 baz EOM cd .. git clone repo worktree

This actually happened when a user tried to port an SVN repository to a Git repository and had ".git" paths in the SVN repository. Using KDEs svn2git utility fast-import accepted the invalid path, but then when trying to checkout during the clone operation, you get the error message

Cloning into 'worktree'... done. error: Invalid path 'foo/.git/bar'

and the worktree stays empty.

I think fast-import should refuse to import paths Git cannot handle properly later on, so that the migration fails early and the frontend that generates the fast-import stream can be fixed / configured to not include such invalid paths.

Regards Björn

On Mon, Mar 18, 2019 at 06:28:16PM +0100, Björn Kautler wrote:

Yeah, that seems quite sensible to me[1].

If you (or anybody else) are interested in working on this, I suspect the answer is to just sprinkle some calls to verify_path() in the right spots. Probably in fast-import.c:file_change_m(), etc.

-Peff

[1] Stretching to think of a way this might backfire, I guess somebody
    could be using Git as an intermediate format to then convert to
    another system. But that seems terribly obscure, and at most I think
    we should give that case an escape hatch to disable the check; it
    should definitely be on by default.

Hi,

I just want to note that this is still reproducible using 2.40.0. :-)

Regards Björn