Reasoning behind separate clone and checkout?

[yamin-oanda]

Is there an existing issue that is already proposing this?

• [X] I have searched the existing issues

Describe the problem imposed by not having this feature

N/A

Describe the solution you'd like

N/A

Other

Hi, this is not really a feature request, it's just a question. (Probably more suited to a GitHub Discussion.) The question is: is there a reasoning behind implementing shallow clone/checkout with two different commands? E.g.:

git clone ${clone_tag_args} --depth << parameters.depth >>

if [ -n "$CIRCLE_TAG" ]; then
          # tag
          git fetch ${fetch_tag_args} --depth << parameters.fetch_depth >> --force origin "+refs/tags/${CIRCLE_TAG}:refs/tags/${CIRCLE_TAG}"
        elif [[ $(echo $CIRCLE_BRANCH | grep -E ^pull\/[0-9]+$) ]]; then
          # pull request
          git fetch ${fetch_tag_args} --depth << parameters.fetch_depth >> --force origin "${CIRCLE_BRANCH}/head:remotes/origin/${CIRCLE_BRANCH}"
        else
          # others
          git fetch ${fetch_tag_args} --depth=<< parameters.fetch_depth >> --force origin "$CIRCLE_BRANCH:remotes/origin/$CIRCLE_BRANCH"
        fi

I'm asking because–wouldn't it be simpler to do it with only a single command? I.e.:

git clone --depth $depth --branch $branch_or_tag $repo_url

Is there a corner case I'm missing, that is handled by doing clone and checkout separately?

[guitarrapc]

@yamin-oanda Hi, thank you for opening issue. The main reason I split clone to two command fetch & checkout is, that's what original CircleCI checkout do. As you can see checkout also split clone step to fetch/checkout commands.

This orb intended to follow original checkout as much as possible, because CircleCI may deploy drastic changes on their checkout logic but orb need to be catched up.

I also initially think to use git clone, but that's the reason.

[yamin-oanda]

Thanks for explaining!