Mixing
`git fetch` followed by `git checkout FETCH_HEAD` checks out seemingly arbitrary unexpected commit
I often am in the position where I want to checkout a specific refspec from the git remote without giving it a name locally. The command I normally use to do this is of the form:
git fetch <remote-url> refs/x/y/z && git checkout FETCH_HEAD
Most of the time this works as expected. That is, I end up in a detached head state on the commit that the refspec refers to. About once a week however, the command completes without error, but I end up on some weird ancient commit somewhere in the ancestor chain that I didn't ask for.
example output:
remote: Counting objects: 25525, done
remote: Finding sources: 100% (396/396)
remote: Total 396 (delta 129), reused 376 (delta 129)
Receiving objects: 100% (396/396), 167.79 KiB | 2.33 MiB/s, done.
Resolving deltas: 100% (129/129), completed with 68 local objects.
From <remote-url>
* branch refs/x/y/z -> FETCH_HEAD
Checking out files: 100% (26834/26834), done.
Previous HEAD position was ...
HEAD is now at 8315f9bc89 Some extremely old commit that is definitely not refs/x/y/z
Executing the exact same command immediately following this gives me the commit I expected to get in the first place.
What could be going wrong here? Considering it says it is setting the FETCH_HEAD to what I asked for and didn't return an error, I don't understand even theoretically why it is in the very next moment pointing to the wrong commit.
What steps would be recommended to debug this? The only pattern I have been able to see is that it is always exactly the same old commit that gets checked out when it goes badly. It doesn't appear to be special in any particular way except that it looks like it is one of the first changes in the repo that has a tag.
git
asked Nov 19 '18 at 12:52
Tim Seguine
2,0341932
add a comment |
I often am in the position where I want to checkout a specific refspec from the git remote without giving it a name locally. The command I normally use to do this is of the form:
git fetch <remote-url> refs/x/y/z && git checkout FETCH_HEAD
Most of the time this works as expected. That is, I end up in a detached head state on the commit that the refspec refers to. About once a week however, the command completes without error, but I end up on some weird ancient commit somewhere in the ancestor chain that I didn't ask for.
example output:
remote: Counting objects: 25525, done
remote: Finding sources: 100% (396/396)
remote: Total 396 (delta 129), reused 376 (delta 129)
Receiving objects: 100% (396/396), 167.79 KiB | 2.33 MiB/s, done.
Resolving deltas: 100% (129/129), completed with 68 local objects.
From <remote-url>
* branch refs/x/y/z -> FETCH_HEAD
Checking out files: 100% (26834/26834), done.
Previous HEAD position was ...
HEAD is now at 8315f9bc89 Some extremely old commit that is definitely not refs/x/y/z
Executing the exact same command immediately following this gives me the commit I expected to get in the first place.
What could be going wrong here? Considering it says it is setting the FETCH_HEAD to what I asked for and didn't return an error, I don't understand even theoretically why it is in the very next moment pointing to the wrong commit.
What steps would be recommended to debug this? The only pattern I have been able to see is that it is always exactly the same old commit that gets checked out when it goes badly. It doesn't appear to be special in any particular way except that it looks like it is one of the first changes in the repo that has a tag.
git
asked Nov 19 '18 at 12:52
Tim Seguine
2,0341932
I'd say, try and make it reproducible so that it gives out the same error consistently (snapshot the initial state if you need to), then run with a verbose/detailed/debug flag to see if you can get more information. You may also want to introduce a time lapse / wait command between the two (followed by another pair of &) to see if it makes any difference.
– jchevali
Nov 19 '18 at 13:31
add a comment |
I often am in the position where I want to checkout a specific refspec from the git remote without giving it a name locally. The command I normally use to do this is of the form:
git fetch <remote-url> refs/x/y/z && git checkout FETCH_HEAD
Most of the time this works as expected. That is, I end up in a detached head state on the commit that the refspec refers to. About once a week however, the command completes without error, but I end up on some weird ancient commit somewhere in the ancestor chain that I didn't ask for.
example output:
remote: Counting objects: 25525, done
remote: Finding sources: 100% (396/396)
remote: Total 396 (delta 129), reused 376 (delta 129)
Receiving objects: 100% (396/396), 167.79 KiB | 2.33 MiB/s, done.
Resolving deltas: 100% (129/129), completed with 68 local objects.
From <remote-url>
* branch refs/x/y/z -> FETCH_HEAD
Checking out files: 100% (26834/26834), done.
Previous HEAD position was ...
HEAD is now at 8315f9bc89 Some extremely old commit that is definitely not refs/x/y/z
Executing the exact same command immediately following this gives me the commit I expected to get in the first place.
What could be going wrong here? Considering it says it is setting the FETCH_HEAD to what I asked for and didn't return an error, I don't understand even theoretically why it is in the very next moment pointing to the wrong commit.
What steps would be recommended to debug this? The only pattern I have been able to see is that it is always exactly the same old commit that gets checked out when it goes badly. It doesn't appear to be special in any particular way except that it looks like it is one of the first changes in the repo that has a tag.
git
asked Nov 19 '18 at 12:52
Tim Seguine
2,0341932
I often am in the position where I want to checkout a specific refspec from the git remote without giving it a name locally. The command I normally use to do this is of the form:
git fetch <remote-url> refs/x/y/z && git checkout FETCH_HEAD
Most of the time this works as expected. That is, I end up in a detached head state on the commit that the refspec refers to. About once a week however, the command completes without error, but I end up on some weird ancient commit somewhere in the ancestor chain that I didn't ask for.
example output:
remote: Counting objects: 25525, done
remote: Finding sources: 100% (396/396)
remote: Total 396 (delta 129), reused 376 (delta 129)
Receiving objects: 100% (396/396), 167.79 KiB | 2.33 MiB/s, done.
Resolving deltas: 100% (129/129), completed with 68 local objects.
From <remote-url>
* branch refs/x/y/z -> FETCH_HEAD
Checking out files: 100% (26834/26834), done.
Previous HEAD position was ...
HEAD is now at 8315f9bc89 Some extremely old commit that is definitely not refs/x/y/z
Executing the exact same command immediately following this gives me the commit I expected to get in the first place.
What could be going wrong here? Considering it says it is setting the FETCH_HEAD to what I asked for and didn't return an error, I don't understand even theoretically why it is in the very next moment pointing to the wrong commit.
What steps would be recommended to debug this? The only pattern I have been able to see is that it is always exactly the same old commit that gets checked out when it goes badly. It doesn't appear to be special in any particular way except that it looks like it is one of the first changes in the repo that has a tag.
git
git
asked Nov 19 '18 at 12:52
Tim Seguine
2,0341932
asked Nov 19 '18 at 12:52
Tim Seguine
2,0341932
asked Nov 19 '18 at 12:52
Tim Seguine
2,0341932
asked Nov 19 '18 at 12:52
Tim Seguine
2,0341932
asked Nov 19 '18 at 12:52
Tim Seguine
2,0341932
2,0341932
I'd say, try and make it reproducible so that it gives out the same error consistently (snapshot the initial state if you need to), then run with a verbose/detailed/debug flag to see if you can get more information. You may also want to introduce a time lapse / wait command between the two (followed by another pair of &) to see if it makes any difference.
– jchevali
Nov 19 '18 at 13:31
add a comment |
I'd say, try and make it reproducible so that it gives out the same error consistently (snapshot the initial state if you need to), then run with a verbose/detailed/debug flag to see if you can get more information. You may also want to introduce a time lapse / wait command between the two (followed by another pair of &) to see if it makes any difference.
– jchevali
Nov 19 '18 at 13:31
I'd say, try and make it reproducible so that it gives out the same error consistently (snapshot the initial state if you need to), then run with a verbose/detailed/debug flag to see if you can get more information. You may also want to introduce a time lapse / wait command between the two (followed by another pair of &) to see if it makes any difference.
– jchevali
Nov 19 '18 at 13:31
I'd say, try and make it reproducible so that it gives out the same error consistently (snapshot the initial state if you need to), then run with a verbose/detailed/debug flag to see if you can get more information. You may also want to introduce a time lapse / wait command between the two (followed by another pair of &) to see if it makes any difference.
– jchevali
Nov 19 '18 at 13:31
add a comment |
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53375069%2fgit-fetch-followed-by-git-checkout-fetch-head-checks-out-seemingly-arbitrary%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53375069%2fgit-fetch-followed-by-git-checkout-fetch-head-checks-out-seemingly-arbitrary%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I'd say, try and make it reproducible so that it gives out the same error consistently (snapshot the initial state if you need to), then run with a verbose/detailed/debug flag to see if you can get more information. You may also want to introduce a time lapse / wait command between the two (followed by another pair of &) to see if it makes any difference.
– jchevali
Nov 19 '18 at 13:31