Hi @John Murray !

Yes, it just works, thanks to @Timothy Leavitt and his team.

The only thing you need is to make sure that your dev module is described via IPM, and install and setup git-source-control.

Here is an example template for interoperability production that demonstrates the feature. 

And here is the only setup line that is needed after git-source-control is installed via IPM:
 

 zpm "install git-source-control"
    do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

@Brett Saviano , maybe I'm mixing something up, but I'm just trying to provide you feedback, that developers that follow the client-side paradigm (actually the majority of existing developers to my knowledge) should still have any option to edit BPL/DTL and DFI and today the way is via server-side UI tools, and of course, they would expect changes reflected in their client git setup, which git-source-control wonderfully does.

1. Yes, but it can add some automation, as for docker-way port can be a random everytime, so this mean manual setup every build. Which is easy to setup, but every time.

2. Yes, UI Integration. And, if we are talking about client-side editing it is possible to edit those files manually (they are just XML files) of course. But ideally, the developer could call a UI in IRIS to edit the file from within a file, and the changes be saved into this file after editing in the IRIS UI app.

3. What exactly is "incorrect"? ) git-source-control perfectly works as a tool to deliver changes made in IRIS developer UI tools into client-side files. Well, you can say that it is server-side editing, and I agree, as every IRIS-driven developer UI tool is on the IRIS side, meaning server-side in this case. But still, it works perfectly and doesn't demand developers to change their client-side approach to a server-side in this case.

I use VSCode client-side coding with IRIS every day. Caveats:

1. it'd be great to ease connection to a dockerised IRIS - especially if docker-compose file is not in the root. Anyway the settings.json is a mandatory component, though it can be just the same all the time.

2. Saving changes for UI elements to changed local files for some components of Interoperability and IRIS BI is not complete. For example, editing pivots in the analyzer, term lists, lookup files, etc.

3. git-source control becomes a must-have for client side editing - especially for UI elements. Maybe we could consider some functionality a mandatory part of ObjectScript extension?