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 clone
immediately 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
Activity
/cc @tmaczukin what do you think of this for v1.7? For me, it complements
GIT_STRATEGY=none
- we don't really want people being forced to use it because of little niggles with clone and fetch.I put together #1756 with some thoughts on a "proper" fix, but I wouldn't like to try it for v1.7 - this seems small and uncontroversial enough to go in, though.
Happy to reduce it to just the '--no-checkout' if you think '-f' is a little risky!
Edited by Nick ThomasReassigned to @tmaczukin
Milestone changed to %v1.7
Mentioned in issue #1569 (closed)
Mentioned in commit c5979d17
thanks a lot guys @nick.thomas @tmaczukin! it's working now like a charm!
mentioned in issue #2011 (closed)
mentioned in issue #1431 (closed)