Support for submodules in diff --base

[fenuks]

I have project with git submodule, that contains common definitions. When I run

optic diff src/openapi.yml --base c27e8b3

I get an error

{
  stack: 'ResolverError: Command failed: git show c27e8b3:src/shared/common.yml\n' +
    "fatal: path 'src/shared/common.yml' exists on disk, but not in 'c27e8b3'\n" +
    ' Error opening file "src/shared/common.yml"\n' +
    '    at /home/me/code/api/node_modules/@useoptic/openapi-io/build/parser/resolvers/git-branch-file-resolver.js:24:32\n' +
    '    at ChildProcess.exithandler (node:child_process:420:5)\n' +
    '    at ChildProcess.emit (node:events:513:28)\n' +
    '    at ChildProcess.emit (node:domain:489:12)\n' +
    '    at maybeClose (node:internal/child_process:1091:16)\n' +
    '    at Socket.<anonymous> (node:internal/child_process:449:11)\n' +
    '    at Socket.emit (node:events:513:28)\n' +
    '    at Socket.emit (node:domain:489:12)\n' +
    '    at Pipe.<anonymous> (node:net:313:12)',
  code: 'ERESOLVER',
  message: 'Command failed: git show c27e8b3:src/shared/common.yml\n' +
    "fatal: path 'src/shared/common.yml' exists on disk, but not in 'c27e8b3'\n" +
    ' Error opening file "src/shared/common.yml"',
  source: 'src/shared/common.yml',
  path: null,
  toJSON: [Function: toJSON],
  name: 'ResolverError',
  footprint: 'null+src/shared/common.yml+ERESOLVER+Command failed: git show c27e8b3:src/shared/common.yml\n' +
    "fatal: path 'src/shared/common.yml' exists on disk, but not in 'c27e8b3'\n" +
    ' Error opening file "src/shared/common.yml"',
  toString: [Function: toString]
}

where src/shared/ is mentioned submodule, and analysed openapi.yml references src/shared/common.yml.

[acunniffe]

Hey @fenuks -- thanks for using Optic. This is a new use case we have not seen before. Are all your common components in the submodule? Is that how you share them across projects? Cool idea.

Re: getting this to work, whenever Optic is invoked with the Git pattern, it stops using the file system and starts using the Git object store. We have some code that makes relative file paths in a$ref into a git name so you can resolve everything from the Git object store.

However this seems to break with submodules. Under the hood we're using git show -- you can see the code here:

https://github.com/opticdev/optic/blob/24a035fb699ee95546463c61eb88e6beec15ff1f/projects/openapi-io/src/parser/resolvers/git-branch-file-resolver.ts#L20

If you can figure out a way to use git show or a similar command to resolve the contents from a submodule please share what you find or open a PR https://git-scm.com/docs/git-show#Documentation/git-show.txt---submoduleltformatgt

That's the easy way, if that does not work, I imagine the logic gets more complex. 1) understand the the repo structure and at what paths the submodules exist 2) then a clever way to go from file reference to submodule reference. It's doable.

Is this something you'd be open to working with us on?

[fenuks]

Hello,

Are all your common components in the submodule? Is that how you share them across projects? Cool idea.

Yes, common definitions are shared among many projects via submodule.

I don't think it would be possible to use git show in context of parent repository, or I don't know how it can be done. I'm afraid that it might be necessary to descend into submodule repository, or add -C path/to/submodule flag. The latter should be easier.

Is this something you'd be open to working with us on?

I'll see what I can do, but I know typescript very little.

[acunniffe]

If you can figure out a git-show or similar command that resolves the sub module files relative to the parent we can do the typescript around it.

None of the people on our team has worked with sub modules so we're a little out of our depth here. Any knowledge you can share would help.

[notnmeyer]

we don't have any immediate plans to support submodule workflows—they're not something we use or have any expertise around. i created an issue in our backlog for tracking interest in submodule support.

@fenuks feel free to reopen this if you can help out with some of the info @acunniffe was asking for.