Version control UX / Git-based PLM

[franknoirot]

While users comfortable using version control like Git can use it today with Modeling App thanks to our plain text representation of CAD projects as folders of KCL and TOML files, having a point-and-click interface will open up that superpower to a much wider audience. Although our interface will likely hook into Git as the industry standard under the hood, I think we should refer to this bucket of features as "version control" to be more recognizable to non-software folks.

Statuses:

• Requirements outlined
• Designs or details created
• Blockers cleared

[franknoirot]

Let's discuss user requirements! What user behaviors do we have to support to ship a version of this that we're proud of?

[franknoirot]

Here's my rough initial list:

1. The app should be able to detect if Git is installed on the user's computer, and if not, be able to ask for permission to install it when the user first tries to use a version control feature.
   1. Alternatively, maybe we could install Git initially to guarantee its there already and has permissions?
2. The app should allow users to initialize the project as a Git repository. This flow should let them:
   1. Set the default branch name (main as a sane default)
   2. Set a remote URL
3. Should allow users to perform the following Git actions from the pane:
   1. Stage files and folders
   2. Mark files and folders as ignored
      1. It should ignore all non-project files by default
      2. Not sure how we could let users mark files as no longer ignored from the UI
   3. Commit with a message
   4. Push to remote
   5. Pull from remote
   6. Merge or rebase from a branch
      1. Not initially, it is too fraught with UX issues
   7. Review visual diff of files using snapshot
      1. Not initially
   8. Checkout branches

[franknoirot]

Let's discuss blockers! What is getting in the way of implementing this for users?

[franknoirot]

Here's my rough list:

• Having the bottom status bar ready (partially, for branch switching/viewing button)
• (maybe) having a better plan for plugins/extensions

Nothing else, that's pretty wild

[franknoirot]

I think if we figured out basic user requirements and designs for this we could probably implement a first version of it, and come back through and excise it into a plugin when we get to that work. Or conversely we can ship the barest-of-bones implementation of what a Plugin should be to lay some separation into the system, and then we have something to build on when we have a more mature idea of plugins.

[Irev-Dev]

think we should refer to this bucket of features as "version control"

But than

I agree with the sentiment of not using git jargon, but then if we just put a UI that proxies git, folks new to it are still going to have to learn the git mental model (what is "staging"?). I definitely am scope creeping the hell out of this,

We'll probably end up just going with "support git" because it's the industry standard, plus the whole "CI for hardware" pitch means plugging into normal CI and therefore the git ecosystem (github, lab, bitbucket etc)

but I would want to at least explore it. I guess questions I have are:

• Is it possible to use git as the base layer, without leaking the abstraction into the UI (can we learn from Jujutsu?).
• What other "git UI" projects have there, how successful is each, and are there any that have successful not leaked git commands in the UI.
• Are there projects that have not used git? (I know that replit offers there one "snapshots" version control, that I think is pretty simple [no forking what so ever] and they can get away with this because they offer real time collaboration, [since forking is kinda needed for async collab]. They can still offer git integration, and the two don't conflict because of this. Is this worth considering)