Adds optional depth parameter for specifying the number of git commits

[maryamklabib]

"Some of the lock repos can get super big really fast, especially if multiple teams/pipelines are using the same repo. An idea is to use shallow clones, since we don't necessarily need the full history of the repo, we just need the latest state."

We wanted to implement the behavior that was requested in issue: #40

This behaves the same exact way as the git-resource, as we wanted to maintain consistency. This is a parameter on the get step, the same way as described here: https://github.com/concourse/git-resource#in-clone-the-repository-at-the-given-ref

Authored-by: Maryam Labib [email protected]
co-authored by: Soumya GB [email protected]

Signed off by: Maryam Labib [email protected]
Signed off by: Soumya GB [email protected]

[maryamklabib]

Any updates on merging this PR?

[vito]

thanks! sorry for the delay, it's pretty hard keeping up with all these resources.

[sc68cal]

Is there ever a time where we wouldn't want the depth to be 1?

I'd suggest setting the default value to be 1 so that users that end up with big lock pool histories don't have to go and hunt for this parameter once their lock pool gets big enough for this to be a problem. I haven't looked through the code for this resource, but if there isn't any conflict resolution in this repo for handling history merges, what is the point of downloading all the history?