Allow shallow cloning when determining versions

[joaopbnogueira]

While I understand why GitVersion asks for a full clone of the repo, this quickly becomes extremely slow on larger repositories that can take up to 10minutes just for a clone/checkout due to a huge history.

Being able to limit the depth is crucial in these situations to have fast CI pipelines.

In my example I'm using tags and conventional commits to determine the next version and don't really need the full history as I'm quite confident all necessary information is present in, say, the previous 200 commits, so having to fetch all history is wasteful.

Is there any flag or option to allow these shallower checkouts?

Thank you

[HHobeck]

Is there any flag or option to allow these shallower checkouts?

No there is no option. If you like you can do a proof of concept by removing the following check:

GitVersion/src/GitVersion.Core/Core/GitPreparer.cs

Lines 191 to 194 in 388b4a3

	if (this.repository.IsShallow)
	{
	throw new WarningException("Repository is a shallow clone. Git repositories must contain the full history. See https://gitversion.net/docs/reference/requirements#unshallow for more info.");
	}

[asbjornu]

Yes, that would be a good start. It should absolutely be possible to somehow configure GitVersion to create a version based on the N last commits, at least if one of them are tagged. If we baked this into the normalization procedure, we could basically do the equivalent of:

git fetch --tags
last_tag=$(git describe --tags --abbrev=0)
commit_count=$(git rev-list $last_tag..HEAD --count)
git fetch --depth $commit_count

This would become even more optimal if we already know the value of $last_tag, which most build systems should be able to provide us with.

[joaopbnogueira]

Just created a PR please comment :)

#4561