cargo new does not create git repository under existing repo (such as git $HOME), even with --vcs git

[joshtriplett]

cargo new silently skips creating a git repository for a path under an existing repository, which includes a git $HOME directory.

At a minimum, --vcs git (or configuration-file equivalent) should override that. There also should be some way to systematically ignore git repositories above a certain point, to always ignore a git home directory. Perhaps that point could default to $HOME.

[alexcrichton]

Yeah I think that --vcs git is basically you saying you really want a new git repository, which I think cargo new should definitely respect. I'd be a bit more wary adding a point at which a repo is not considered as being "in another repo", but we can certainly at least start with the flag!

[joshtriplett]

As one possibility, cargo new could respect the git environment variable "GIT_CEILING_DIRECTORIES" (see "man git"), which specifies directories that git should not traverse upward past when looking for a .git directory. Then I could specify $HOME/src in that variable and git wouldn't navigate upward all the way from projects under ~/src/ up to $HOME.

And given the code to respect that variable, cargo could also support specifying that same value in a configuration file (to limit it to just cargo).

[ches]

👍 to this, and perhaps obviously it should apply to Mercurial as well. Same use case as @joshtriplett except that my home directory is an hg repository rather than git (for dotfiles as you might guess, everything ignored and tracking only explicitly added files). Because of this and because ~/src is where I generally keep all my work, cargo new --vcs (and its default value of git) are effectively dead to me in practice. Whether I'd want to use --vcs git or --vcs hg, either is ignored because my $HOME/.hg is discovered.

libgit2's git_repository_discover function has a ceiling_dirs parameter that corresponds to the environment variable @joshtriplett pointed out. Unfortunately right now git2-rs doesn't support this, acknowledging with a TODO that it diverges significantly from libgit2.

Since Cargo handles Mercurial more crudely on this matter currently (just shelling out to hg root for lack of having any library to use), it could check something like hg --repository . root to look no higher than current working directory, but it wouldn't make sense to change without a consistent approach for Git as well.

IMO this is the sort of reason that some people would prefer Cargo not being opinionated on Git by default (see #1099). It's trying to be helpful with a default, but here it actually seems to create complication and constrains thinking about Crate's design and usage. Note how bundle gem mynewproject in Ruby still to this day requires Git, which I frankly find a little sad.

Yeah I think that --vcs git is basically you saying you really want a new git repository, which I think cargo new should definitely respect.

I agree, and I think this becomes even clearer and easier to argue if the default were --vcs none. No clever (surprising) discovery at all: either you specify a --vcs and you get it, or you don't and, um, you don't. (Okay, Cargo's implementation could still sanity check that repo metadata doesn't already exist where it's been asked to create it, but for the user in non-exceptional cases this model is a lot more straightforward, and probably for the implementation too in the long run). I didn't used to feel strongly about the none default, but the preceding line of thinking is beginning to convince me.

[ches]

Just to plainly state another use case for the record, submodules are another situation where I would want cargo new --vcs git to mean "no really, stop with your clever discovery, I'm specifying this option because I really mean it...".

[joshtriplett]

Any update on this? Just re-encountered this issue again.

There appear to be three separate issues here, one easier than the other:

First, and most importantly, "--vcs git" should always create a repository, and should never assume an existing repository. That seems easiest to fix.

Second, there's the question of whether "cargo new" without --vcs should automatically assume "--vcs git". No opinion there other than "encouraging version control seems nice".

And third, it'd be nice to do the right thing automatically by respecting GIT_CEILING_DIRECTORIES or similar, but that apparently needs to wait on a git2-rs update.

Leaving the second and third issues aside, what would it take to fix the first, and make --vcs git always make a git repo?

[alexcrichton]

@joshtriplett there has been no progress on this.