VCS: remove unused methods and make new Git pattern the default

[humitos]

This PR removes the feature flag to use the new Git pattern, making it the default. Besides, it removes some methods that are not used anymore because we are always cloning the repository, so there is no need to update it or similar.

Closes #8940

Related

• Can't set "Default branch" after converting repo from hg -> git #9108
• Manual project import: Fails to detect Github "main" branch #9367
• Start deprecating old VCS support #8840
• Build: replace GitPython with git commands #10594

[humitos]

There were some changes in our code, but this PR is still useful. I'll try to come back to it when I have some extra time.

[humitos]

I updated this PR but there are still some extra work to do, so I'm leaving it again 😄

IMO, it would be good to deprecate and remove some VCS as already proposed (mainly SVN and bzr) to reduce the complexity and scope of this refactor.

Also, we should probably avoid keep using gitpython and go back to parse git's output (I think @stsewd already mentioned this in another issue). However, this should be simpler now because we are already doing this with ls-remote and it's working fine. Branches and tags will use the same command to get these. The only new command we will be introducing to parse its output would be git submodule to discover them.

[humitos]

I updated this PR again. The main new work here is that it makes the new Git pattern the default. I has been enabled for more than a week already and we haven't had any support issue about this. So, I think we are ready to remove the feature flag from our code.

IMO, it would be good to deprecate and remove some VCS as already proposed (mainly SVN and bzr) to reduce the complexity and scope of this refactor.

I'm still 👍🏼 on this, but I'm not going to cover it on this PR since it requires to follow our deprecation plan. I will do this work on #8840 in the next sprint.

Also, we should probably avoid keep using gitpython and go back to parse git's output

We are tracking this in another issue, so we will be following it there: https://github.com/readthedocs/readthedocs-corporate/issues/1524

[humitos]

I will update this PR once Santos merges the work from #10594 so we don't compete for this chunk of code.

[humitos]

Blocked by #10606

[humitos]

This is ready for review now 👍🏼

[stsewd]

We should merge this after we have tested the new implementation more broadly again.

[emmettbutler]

Is it possible to tell a build to use the default prior to this change? It seems possible that this change broke dd-trace-py's release notes workflow. DataDog/dd-trace-py#7176

[stsewd]

@emmettbutler it's not possible, if you need to unshallow you can follow the example from https://docs.readthedocs.io/en/stable/build-customization.html#unshallow-git-clone, or maybe the suggestion from #10795.