Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propagate existing VCS to subprojects #7673

Closed
wants to merge 1 commit into from

Conversation

Iniesta8
Copy link

@Iniesta8 Iniesta8 commented Dec 6, 2019

With this post, when creating a new project within an existing project, any existing VCS is reused by creating a matching ignore file in the new subfolder. (see issue #6357)

  • If a VCS is explicitly given, e. g. by config or by command line option a new VCS environment will be initialized
  • If there is no VCS explicitly given and we are not in an existing VCS environment, Git will be initialized
  • If there is no VCS explicitly given and we are in an existing VCS, we propagate this VCS into the subproject

With this post, when creating a new project within an existing project, any existing VCS is reused by creating a matching ignore file in the new subfolder. (see issue rust-lang#6357)
@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 6, 2019
@ehuss
Copy link
Contributor

ehuss commented Dec 8, 2019

Thanks for the PR, but I think this is working as intended. If new packages are created within a workspace, I wouldn't want it to create extra .gitignore files. I think this is somewhat fundamental to cargo new not knowing the intention of the user, so it can be difficult for it to make a choice.

@bors
Copy link
Collaborator

bors commented Jan 8, 2020

☔ The latest upstream changes (presumably #7776) made this pull request unmergeable. Please resolve the merge conflicts.

@ehuss
Copy link
Contributor

ehuss commented Jan 10, 2020

I'm going to close this for now. Feel free to follow up on the issue tracker. However, I'm not sure if there is a clear path forward since Cargo doesn't really know how the new project is intended to be used (such as in a workspace or not). This also creates nested repositories which doesn't seem like the right behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants