Panics if a commit references nonexistent submodule commit about git-submerge HOT 5 CLOSED

Instead of panicking, we could finish walking through the history, collect all the other dangling references, then report them all to user. The user can then provide a mapping between non-existent and existing commit IDs using one of the three methods:

• --default-mapping <commit> will use <commit> instead of any that couldn't be found. Option can be specified only once;
• --mapping <commit1> <commit2> will map <commit1> to <commit2>. Option can be specified multiple times;
• --mappings-file <filename> where <filename> is a file containing two space-separated columns, the first one being the old commit ID and the second one is new commit ID.

from git-submerge.

Another option is to provide something like rebase's interactive mode: when the problem is encountered, we check out the tree and let the user fix everything, than just carry on until the new problem is found. I doubt the user will be able to do much to fix anything, though.

from git-submerge.

The commit IDs provided by the user should be checked, too:

• <commit> in --default-mapping should exist in original submodule history;
• <commit2> in --mapping and --mappings-file should exist in original submodule history.

from git-submerge.

We should thoroughly document how situations like that could even happen (spoiler: history rewriting), and what the user can do to resolve them (spoiler: find the repo that still has original history).

from git-submerge.

fdd04ca implements everything mentioned in this issue.

from git-submerge.