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.