frej / fast-export

A mercurial to git converter using git-fast-import
http://repo.or.cz/w/fast-export.git
808 stars 255 forks source link

Not all modules are defined in mapping file. #284

Closed fabio-solidify closed 1 year ago

fabio-solidify commented 2 years ago

Hi! We are trying to convert hg subrepos to git submodules using the fast-export submodule feature. But the script is complaining that we don’t have defined all submodules in the mapping file. When examining the hg-fast-export.py we can se that you are starting to look at rev 0. For our case, the repo in rev 0 had 3 submodules, but the most recent revision (167) had only two submodules. So, for the script to work we have to checkout revision 0 (picture 3) for the hg-repo that we want to convert before doing the actual conversion. And then check the .hgsub file (for rev 0) for subrepos and add them to the mapping file. But one of this subrepos is not going to be a part of the latest revision (167). The nature of our script is that we are creating remote repositories on the fly for all submodules. Going back to rev 0 means we are creating a repository that is not going to be used later. What am I missing here?

This is also going to be a problem in the feature. What happens if a submodule is added in a specific revision? Then the mapping file provided would be wrong again. There’s nothing in the documentation about this . The assumptions there is that you just need to clone your hg repo, and then git init a folder for every submodule and parent, use the script to convert them with the provided mapping file and push.

We have tried to comment out this section of the code and didn't get any errors. But I don't know the internals of hg-fast-export.py so I don't know if this breaks something.

Picture 1 adding more print statements to see what’s going on. image

Picuture 2 Original code image

Picture 3 Here we have to checkout 0 revision in order to get the script working. image

frej commented 2 years ago

You have to have an entry for each subrepo which is referenced from anywhere in the super repository history. As the submodule documentation shows, it is a requirement to convert all submodules before converting the super repository.

Converting a subrepo could require you to checkout a revision in the super repository where the subrepo exists (it could be that you want the revision just before the removal, if the subrepo is removed).

Going back to rev 0 means we are creating a repository that is not going to be used later.

It will be referenced from the converted super repository.

The nature of our script is that we are creating remote repositories on the fly for all submodules.

What script? Fast-export can't work with remote repositories.

What happens if a submodule is added in a specific revision?

There is nothing wrong with a mapping for a submodule which doesn't exist for the whole history of the super repository. On the other hand, fast export will surely break if you for example remove a subrepo and then add a new repo at the same path within the super repository as there is no way to map two different submodules to the same path (patches welcome).

frej commented 1 year ago

No response in more than six months, closing.