I was looking at the git resource and found it curious that Check is doing a clone rather than the much more lightweight ls-remote. I think there are two reasons:
The first one is obvious, but I don't see the reason for the second.
It is given the configured source and current version on stdin, and must print the array of new versions, in chronological order, to stdout, including the requested version if it's still valid.
But then later it says:
If your resource is unable to determine which versions are newer than the given version (e.g. if it's a git commit that was push -fed over), then the current version of your resource should be returned (i.e. the new HEAD).
So my question is, why can't a resource always just return a single version - the latest. I.e. not even the requested version if the source has moved on? What functionality would be lost?
Note that this question is related to Implemented a Resource Type: How does Concourse use the output of the check, in, and out scripts?
If you were to do it that way, your resources would appear with one set of versions, and your get steps would not return the version of the file that was explicitly requested (the version returned by check is passed to in), which would be a violation of the resource type design, and frankly, a bad practice (why would you return something that wasn't requested just because it was newer? what if you need to pin a resource to a specific version?)
The answer to why the git resource does clone instead of ls-remote is because you can configure the resource to recognize new versions only if certain files are changed (or the inverse of that, if there was a new commit but the files changed were in the ignore_paths stanza of the source configuration, check does not return the new resource.
So the biggest question is, why do you want to do that? Ease of programming? Performance concerns?