This helps but doing a git clone at all is pretty rough on performance for larger repositories. It ends up copying parts of the .git folder as well as a full checkout. Ideally only the current commit could be copied via a worktree, or even just git archive --format=tar master | tar -C /tmp xf - to scrap the git repo entirely but unfortunately I don't think that's a viable option as subsequent commands rely on it being a valid repo in order to grab submodules.

https://github.com/Kentzo/git-archive-all

Maybe useful?

Yeah after I looked to see what other things were happening that I wasn't hitting this PR won't work particularly well. For example the --depth=1 assumes your $REV will be in that range. Need a way to archive a particular commit without cloning the entire history of the repo into a temp folder per-build.

A git worktree add would work nicely but I don't think we are allow to depend on git 2.x.

We can depend on whatever we want if it provides improved "something" imo. We do that for nginx for instance.

I've pushed an update that seems to work well and dramatically speeds up my builds on larger repositories.

Thats pretty clever.

I'm not super familiar with git submodules but I think this approach may still clone the entire submodule. Using git-archive-all might fix that but is unrelated to my use-case at least. It appears there is a --depth option to git submodule if we wanted to go deeper down the rabbit hole.

Does this hamstring us from doing rollbacks later?

I'm not sure what you mean but afaict these are tmp folders so they will be gone after reboot at the least so if any plugins are relying on them sticking around they're gonna have a bad time. The code is already doing a rm -rf .git on the line below my changes as well so I can't see how it'd cause any extra git-related issues with future features.

👍 on what @mmerickel said. I'm not sure how this would hurt anything, so long as the state of the original git repo stays as is.

My first glance was cursory at best. Looking more closely, this just puts the one ref into the container, yes?

We could delete the ref inside that new copy of the branch, no?

Are you referring to the temporary tag as the ref being injected? I could add a line to delete the ref, but again the .git folder is deleted just below this regardless.

I think this is fine as is. I was merely confirming what I was reading.

Tests should pass now. Please rebase.

Things should be good after these tests finish running.

Gave it the old college test locally. lgtm 👍

This seems to fail for repositories where submodules are not at HEAD due to the added --depth=1 flag. As that is a breaking change, I am thinking we should either back it out or allow users to fallback to non-depth=1. Thoughts @mmerickel ?