Export & Import Git Graph Repository Configuration (for sharing within teams)

[ntziolis]

I was able to successfully configure both pull requests + issue linking via the repository settings widget. Our intent is to share these settings within the team. However I could not figure out where these settings are stored.

I checked:

• vs code settings for (user / container + workspace)
• git config (both local as well as global)
• in addition there are also no new files in the repository where config is stored

[mhutchie]

Hi @ntziolis,

All repository configuration performed within the Git Graph View is stored internally within Visual Studio Code's Workspace State Memento API, and is therefore not currently available to be shared with other users. For numerous reasons, this is definitely the method that should be used by Git Graph.

I definitely want to better support teams using Git Graph going forward. I'll change this question into a feature request, for the ability to export all of a repositories configuration from Git Graph to a convenient *.json file (including Issue Linking and Pull Request Creation), which can be shared within a team, and imported into their own installations of Git Graph. I'll include this in an upcoming release.

[ntziolis]

Hi @mhutchie,

I see thank you for the info. If I understand the way Memento works correctly, information is stored per combination of vscode / "system user profile".

If so this presents another more severe issue for us:

• When developing using the Remote: Container feature of vscode all development happens in a dev container
• Part of the ongoing process developing when developing with containers is regularly rebuilding the dev container, reasons could be
  • Container definition was changed (new global dependency / lib needs to be installed)
  • Some problem arises with the container (could be anything from connection to executing a bad shell command)
• If a container is rebuild the entire machine is recreated from scratch, which means all Memento data will be lost
• Hence Pull Request / Issue Tracking needs to be reconfigured after each container rebuild
• The reconfiguration effort compounds as each projects has its own dev container, which means this has to be done every time a rebuild container is done for any project
  • We are a dev shop and serve many clients hence we have usually a few ongoing projects at the same time
  • One of the main reasons we are using dev containers is it simplifies context switching while ensuring always having a working environment
  • This comes in especially handy if a client comes back in 2 years later and wants a small change done on a node 8 app

To give you an idea how often a container gets rebuild:

• I worked on 3 different projects last week
• One being the my main current project with 3-5 rebuilds for that project alone
• For the other 2 projects I had ran one rebuild the container each (as colleagues had added additional global dependencies since the last time I worked on those projects)
• The above represents a fairly usual week

The rebuild container issue also applies to Github Codespaces which basically are the same thing as using Remote: Container locally, but simply with the container being hosted online.

We are very keen to assist you to migrate these settings to a place where they can be committed in the project, since this is the last remaining piece to allow us to heavily reduce tool switching between vscode / SmartGit / Azure Devops.

Do you have any guidance / preference how this could be solved and I'm happy to work with my team to create a PR.

[mhutchie]

Hi @ntziolis,

Thank you for the additional details, it’s really useful to know the scenario you’re working with!

I’ll have a think about the best path forward for implementing this capability, there a lot of considerations that need to be made. Some solutions I’ve already considered initially seem feasible and simple, however on deeper exploration each present their own challenges.

I’ll reply back on this thread once I’ve thoroughly gone through all of the possible solutions, and am confident with the direction Git Graph should take.

[ntziolis]

Totally understand that there are other items on the list as well. So knowing this might take a while since you have:

• Do you know of a way to run a script to load data into Memento?
• Could you confirm
  • If our understanding is correct that the config for all repos is stored in a single key?
  • And if so if this is the name of the we would need to store
    • https://github.com/mhutchie/vscode-git-graph/blob/0a1293fb00076a7a5625ec0f38353b86aca7ce5d/src/extensionState.ts#L17

[mhutchie]

Hi @ntziolis,

To load data into Memento’s, you’d have to clone the repo, create some mechanism in the extension (via calling ExtensionState.saveRepos), package it into an alpha release, and install it.

I’m quite happy to prioritise this request, and implement & make it available in a beta release for your team to use within the next week. Even though this is the first feature request for this capability, it is long overdue in Git Graph so I intend to get it out really quickly.

[ntziolis]

@mhutchie ok wow, did not expect you to be working on this so soon. We will def. hold our efforts then. Also again, if we can assist in the development please let us know. Since we will be using git-graph as the backbone of our operations moving forward we would be committed to assist you with continuous development to fix bugs + add features (and not just the ones that affect us directly). Just lmk.

[mhutchie]

This will be available in v1.28.0 (which I intend to release on 29/11/2020).

From the change log:

• 414 Your Git Graph Repository Configuration can now be exported to a file that can be committed in the repository. It allows others working in the same repository to automatically use the same Git Graph configuration. In order to export your configuration, click the "Export Repository Configuration" button at the bottom of the Repository Settings Widget (on the Git Graph View).

If you'd like to use it before the next release, you can download v1.28.0-beta.3, and install it following the instructions provided here.