Allow lhs and rhs to target git branches

[AlitzelMendez]

I think this was explained by @pshao25 in another issue.

But basically, during all migrations, the original swagger files are deleted as they have been migrated, and the new swagger file is generated. So, at the end, we have a pull request containing only the new swagger file.

Right now, using the tool under the workflow is not very user-friendly. My expectation is that LHS can reference a remote location (repository link to the target branch) and we can run the tool. Of course, the tool can just follow the link, take the files, save them in an internal folder under .gitignore, and work with those swagger files.

However, the fact that people need to keep the files in an additional folder, run the tool, and ensure they never mess up pushing those files makes it feel like the tool can't be easily run with the common-neutral scenario, which is that the original swagger files are no longer there.

Additionally, supporting this scenario will help us in the future if we want to integrate the tool to the pipeline.

[tjprescott]

This is a logical ask, albeit non-trivial, but it will inject even more complexity into the tool. Currently, git is not integrated. It might make more sense for the git operations to be handled via script--this is likely what CI would do. However, I can investigate this.

[pshao25]

@tjprescott I agree with you. I think it's better to be handled by script, not by the tool.

[tjprescott]

We should still provide a way to support the local dev scenario as naturally as possible even if on the EngSys side they can do the git magic.

The current design of the tool was based on the observation by early users that they kept their original Swagger in place, and put their rough generated Swagger somewhere else, but I agree with you both that the actual process would be that you compile your TypeSpec into its ultimate destination, which would bulldoze the old files.

So git integration is an option, though I fear it would add a lot of complexity. Another option might be documentation or a tsp-client command that you run first that basically copies your old Swagger before you bulldoze it.