Skip to content

Use git clone --no-checkout and git checkout --force

What does this MR do?

Adds --no-checkout to git clone and -f to git checkout

Why was this MR needed?

On a case-insensitive filesystem, mixed-case commits can unconditionally break both clone and fetch, as the initial, implicit checkout of HEAD in git cloneimmediately modifies the working tree, which causes the later git checkout to fail (without -f). --no-checkout skips the implicit checkout, and should be fine in all circumstances.

With the fetch strategy, this still isn't enough as the case-insensitivity-caused change persists, and the checkout for the second build fails. -f forces it to proceed, "overwriting" the local changes. This also prevents local modifications brought about by CR/LF differences, or others not caught by the git clean and git reset, from breaking the fetch strategy.

Both these arguments are present in git v1.6.1

Are there points in the code the reviewer needs to double check?

Are there circumstances where we want the build to fail, that git checkout -f would in fact succeed in? I can't think of any offhand.

Does this MR meet the acceptance criteria?

  • Documentation created/updated
  • Tests
    • Added for this feature/bug
    • All builds are passing
  • Branch has no merge conflicts with master (if you do - rebase it please)

What are the relevant issue numbers?

Closes #1296 (closed)

Merge request reports