Add version control support to `spin new` or spin CLI

[me-diru]

I wondered if adding a flag or an interactive prompt (a few ways suggested by @calebschoepp) asking for a Git repository initialization might help people get going from the start with their Spin application and track their code from the beginning.

Maybe we can take their github/gitlab-username in spin.toml

[calebschoepp]

I imagine it could be something like how cargo new works where there is a --vcs flag and a default. Likely we would start with options none or git. We can of course bikeshed the flag name and what the default is.

[calebschoepp]

Maybe we can take their github/gitlab-username in spin.toml

@me-diru Mind elaborating on what you mean by this?

[itowlson]

As a heads up we already have a --no-vcs flag, which I think suppresses .gitignore. Having a --vcs and --no-vcs which affect different things might be a bit regrettable.

[me-diru]

Maybe we can take their github/gitlab-username in spin.toml

@me-diru Mind elaborating on what you mean by this?

I thought we could input from the users in the top-level information in spin.toml to automate and set repository information in .git folder. However, I think --vcs flag that you shared covers this case as well.

[itowlson]

Are you suggesting we set up git config, or set a remote? I'd be extremely wary of that. Running git init for them is about as far as I'd want to go.

[calebschoepp]

+1 to be wary about setting up a remote. I think all we should do is git init.

[me-diru]

As a heads up we already have a --no-vcs flag, which I think suppresses .gitignore. Having a --vcs and --no-vcs which affect different things might be a bit regrettable.

thanks for pointing this out! Indeed, since we are generating a .gitignore with the spin new by default, maybe adding a git init is a good start?

Both will be ignored with --no-vcs flag

[me-diru]

Are you suggesting we set up git config, or set a remote? I'd be extremely wary of that. Running git init for them is about as far as I'd want to go.

+1 to be wary about setting up a remote. I think all we should do is git init.

Agree :D git init should be enough

[calebschoepp]

Sticking with just the --no-vcs flag is good IMO. The default would then be that we try to run git init unless you pass --no-vcs. We should of course gracefully fail if we can't run git init. Perhaps emitting some kind of spin_terminal::warn!("Failed to initialize a git repository for you").

[itowlson]

I am okay with that. So the proposed behaviour is:

• By default, spin new attempts to run git init in the newly created directory.
  • spin add does NOT attempt to run git init.
  • Failure to git init is ~not an option~ not an error.
• The existing --no-vcs flag will suppress the git init (as well as its existing functionality).

Sound good? Anything more we need to specify? Unless there are any curlies here I'm gonna get out my big blue good-first-issue pen for this.

[me-diru]

Thanks for laying that out so clearly. I will look into how to implement it :D

[lann]

I would suggest another check: git -C <new dir> rev-parse

If this succeeds then <new dir> is already (within) a git repo and git init should be skipped.

This will avoid creating unwanted nested repos if you are adding a spin app to some other project.

[iamrajiv]

Hi @calebschoepp, just checking in. If this has not been picked up yet, I would be happy to work on it. Would you be assigning this?

[calebschoepp]

That would be great. I don't believe @me-diru is working on this anymore (please correct me if I'm wrong).

Feel free to start working on it! I don't have the permissions to assign it to you, but I'm sure someone else with the correct permissions will be able to help.

[me-diru]

Yes, @iamrajiv hope you have fun working on this one!!

[iamrajiv]

Thanks @me-diru @calebschoepp! I went through the issue and the discussion, and here’s what I’ve gathered and what I think I need to do is so:

• By default, spin new should try to run git init in the newly created directory
• For spin add, we should not run git init — it’s only meant for new applications
• If git init fails, that’s okay — just show a warning, no need to treat it as an error
• The existing --no-vcs flag should still disable both .gitignore creation and this new git init behavior
• And before running git init, we should check if the directory is already inside a Git repo to avoid nesting

Just want to confirm is that everything I need to take care of right?

I’ve created the PR: https://github.com/spinframework/spin/pull/3155 could you please take a look when you get a chance?