{"thread":{"id":"46208","subject":"Behavior of 'git fetch' for commit hashes","startedAt":"2017-06-19T12:19:34Z","lastAt":"2017-06-20T11:32:57Z","messageCount":5,"participants":["eero.aaltonen@vaisala.com","Stefan Beller","Jonathan Tan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"322560","messageId":"14e804c6-0798-8bbd-b182-66c3cd2b870c@vaisala.com","threadId":"46208","inReplyTo":null,"subject":"Behavior of 'git fetch' for commit hashes","fromName":"","fromEmail":"eero.aaltonen@vaisala.com","sentAt":"2017-06-19T12:09:28Z","receivedAt":"2017-06-19T12:19:34Z","isPatch":false,"sender":{"key":"eero.aaltonen@vaisala.com","avatar":null},"body":"Hello,\n\nI am seeing greatly different behavior for 'git fetch' commands on\nversion 2.7.4 and 2.13.1 when the argument to fetch is a commit hash.\n\nI am working on a custom Continuous Integration (CI) system. The\nprojects have dependencies that are simply fetched as repositories to a\nproject subdirectory.\n\nIn order to prevent a race condition in updating branches, I want to\ncheckout the actual commit that was built in a previous job.\n\nEnvironment\n===========\nProblem occurs with Git clients\n- 2.7.4\n- 2.13.1\n\nand Git server\n- Atlassian Bitbucket v4.14.3\n- git version 2.12.0\n\n\nThe problem can be reproduced as follows, with\n- = URL to primary repository\n- = URL to fork of the primary\n- commit hash in a recent branch\n\n1. git clone \n2. cd resulting_directory\n3. git fetch \n\nFor version 2.7.4\n=================\nGit exits with exit code 1.\n\nHowever, if I first do 'git fetch ', then 'git fetch will\nalso work\n\n * branch -> FETCH_HEAD\n\nFor version 2.13.3\n==================\nGit exits with exit code 128 and message\nfatal: Couldn't find remote ref\n\nHowever, the workaround for descbibed abot for git version 2.7.4 no\nlonger works. The result is always\nfatal: Couldn't find remote ref\n\nDesired result\n==============\nCommit is in .git/FETCH_HEAD and can be checked out.\n\n\nI want to checkout a specific commit without creating any extra named\nremotes in the local git clone.\n\nFinally,\nWhat is the expected behavior for 'git fetch' in this case?\nIs there some other way I can achieve my goals?\n\n-- \nBest regards,\nEero Aaltonen"},{"id":"322569","messageId":"CAGZ79kbFeptKOfpaZ23yK=Zw9mJ0_evqPstHKkD1HSCaP_pC5g@mail.gmail.com","threadId":"46208","inReplyTo":"14e804c6-0798-8bbd-b182-66c3cd2b870c@vaisala.com","subject":"Re: Behavior of 'git fetch' for commit hashes","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-06-19T15:50:34Z","receivedAt":"2017-06-19T15:51:22Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"+cc Jonathan who did some work in the area.\n\nOn Mon, Jun 19, 2017 at 5:09 AM, wrote:\n> Hello,\n>\n> I am seeing greatly different behavior for 'git fetch' commands on\n> version 2.7.4 and 2.13.1 when the argument to fetch is a commit hash.\n>\n> I am working on a custom Continuous Integration (CI) system. The\n> projects have dependencies that are simply fetched as repositories to a\n> project subdirectory.\n>\n> In order to prevent a race condition in updating branches, I want to\n> checkout the actual commit that was built in a previous job.\n>\n> Environment\n> ===========\n> Problem occurs with Git clients\n> - 2.7.4\n> - 2.13.1\n>\n> and Git server\n> - Atlassian Bitbucket v4.14.3\n> - git version 2.12.0\n>\n>\n> The problem can be reproduced as follows, with\n> - = URL to primary repository\n> - = URL to fork of the primary\n> - commit hash in a recent branch\n>\n> 1. git clone \n> 2. cd resulting_directory\n> 3. git fetch \n>\n> For version 2.7.4\n> =================\n> Git exits with exit code 1.\n>\n> However, if I first do 'git fetch ', then 'git fetch will\n> also work\n>\n> * branch -> FETCH_HEAD\n>\n> For version 2.13.3\n> ==================\n> Git exits with exit code 128 and message\n> fatal: Couldn't find remote ref\n>\n> However, the workaround for descbibed abot for git version 2.7.4 no\n> longer works. The result is always\n> fatal: Couldn't find remote ref\n>\n> Desired result\n> ==============\n> Commit is in .git/FETCH_HEAD and can be checked out.\n>\n>\n> I want to checkout a specific commit without creating any extra named\n> remotes in the local git clone.\n>\n> Finally,\n> What is the expected behavior for 'git fetch' in this case?\n> Is there some other way I can achieve my goals?\n>\n> --\n> Best regards,\n> Eero Aaltonen\n"},{"id":"322582","messageId":"20170619104936.706eff69@twelve2.svl.corp.google.com","threadId":"46208","inReplyTo":"14e804c6-0798-8bbd-b182-66c3cd2b870c@vaisala.com","subject":"Re: Behavior of 'git fetch' for commit hashes","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2017-06-19T17:49:36Z","receivedAt":"2017-06-19T17:49:48Z","isPatch":false,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"On Mon, 19 Jun 2017 12:09:28 +0000\n wrote:\n\n> For version 2.7.4\n> =================\n> Git exits with exit code 1.\n> \n> However, if I first do 'git fetch ', then 'git fetch will\n> also work\n> \n> * branch -> FETCH_HEAD\n\nI suspect that what is happening is that 'git fetch ' also\ndownloads the commit referenced by , so the subsequent 'git fetch\n' is a no-op (except setting FETCH_HEAD).\n\n> For version 2.13.3\n> ==================\n> Git exits with exit code 128 and message\n> fatal: Couldn't find remote ref\n> \n> However, the workaround for descbibed abot for git version 2.7.4 no\n> longer works. The result is always\n> fatal: Couldn't find remote ref\n\nI'll take a look into this.\n\n> Desired result\n> ==============\n> Commit is in .git/FETCH_HEAD and can be checked out.\n> \n> \n> I want to checkout a specific commit without creating any extra named\n> remotes in the local git clone.\n> \n> Finally,\n> What is the expected behavior for 'git fetch' in this case?\n> Is there some other way I can achieve my goals?\n\nI'll take a look into the expected behavior, but if my assumptions are\ncorrect, you should be able to just checkout the commit you want after\nfetching the branch:\n\n git fetch \n git checkout \n"},{"id":"322626","messageId":"20170619152658.4559bce4@twelve2.svl.corp.google.com","threadId":"46208","inReplyTo":"20170619104936.706eff69@twelve2.svl.corp.google.com","subject":"Re: Behavior of 'git fetch' for commit hashes","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2017-06-19T22:26:58Z","receivedAt":"2017-06-19T22:27:09Z","isPatch":false,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"On Mon, 19 Jun 2017 10:49:36 -0700\nJonathan Tan wrote:\n\n> On Mon, 19 Jun 2017 12:09:28 +0000\n> wrote:\n> \n> > For version 2.13.3\n\nFirstly, exactly which version of Git doesn't work? I'm assuming 2.13.1\n(as written elsewhere in your e-mail), since 2.13.3 doesn't exist.\n\n> > However, the workaround for descbibed abot for git version 2.7.4 no\n> > longer works. The result is always\n> > fatal: Couldn't find remote ref\n> \n> I'll take a look into this.\n\nI tried to reproduce with this script, but it seems to pass even at\n2.13.1:\n\n #!/bin/bash\n rm -rf ~/tmp/x &&\n make --quiet &&\n ./git init ~/tmp/x &&\n ./git -C ~/tmp/x fetch --quiet ~/gitpristine/git master:foo &&\n ./git -C ~/tmp/x fetch ~/gitpristine/git \"$(git -C ~/gitpristine/git rev-parse master^)\"\n exit $?\n\nCommenting out the first fetch line produces, as expected:\n\n error: Server does not allow request for unadvertised object \n\nAnd I have not seen the \"fatal: Couldn't find remote ref\" error you\ndescribe.\n\nAs Stefan alluded to in his earlier e-mail [1], I made a change recently\nto how \"git fetch\" handles literal SHA-1s in commit fdb69d3\n(\"fetch-pack: always allow fetching of literal SHA1s\", 2017-05-15). In\nthis case, I don't think that's the cause of this issue (since that\nchange, if anything, makes things more permissive, not less) but that\nmight be a point of interest in an investigation.\n\n[1] https://public-inbox.org/git/CAGZ79kbFeptKOfpaZ23yK=Zw9mJ0_evqPstHKkD1HSCaP_pC5g@mail.gmail.com/\n"},{"id":"322729","messageId":"be81c12a-75b1-386b-d075-f92ee72ddfce@vaisala.com","threadId":"46208","inReplyTo":"20170619152658.4559bce4@twelve2.svl.corp.google.com","subject":"Re: Behavior of 'git fetch' for commit hashes","fromName":"","fromEmail":"eero.aaltonen@vaisala.com","sentAt":"2017-06-20T11:32:48Z","receivedAt":"2017-06-20T11:32:57Z","isPatch":false,"sender":{"key":"eero.aaltonen@vaisala.com","avatar":null},"body":"On 20.06.2017 01:26, Jonathan Tan wrote:\n> On Mon, 19 Jun 2017 10:49:36 -0700\n> Jonathan Tan wrote:\n> \n>> On Mon, 19 Jun 2017 12:09:28 +0000\n>> wrote:\n>>\n>>> For version 2.13.3\n> \n> Firstly, exactly which version of Git doesn't work? I'm assuming 2.13.1\n> (as written elsewhere in your e-mail), since 2.13.3 doesn't exist.\n\nYes. 2.13.1. I should stick to copy-pasting.\n\n> I tried to reproduce with this script, but it seems to pass even at\n> 2.13.1:\n> \n> #!/bin/bash\n> rm -rf ~/tmp/x &&\n> make --quiet &&\n> ./git init ~/tmp/x &&\n> ./git -C ~/tmp/x fetch --quiet ~/gitpristine/git master:foo &&\n> ./git -C ~/tmp/x fetch ~/gitpristine/git \"$(git -C ~/gitpristine/git rev-parse master^)\"\n> exit $?\n> \n> Commenting out the first fetch line produces, as expected:\n> \n> error: Server does not allow request for unadvertised object \n> \n> And I have not seen the \"fatal: Couldn't find remote ref\" error you\n> describe.\n\nI am now getting the same \"unadvertised object\" error. The \"remote ref\"\nerror it seems was due to missing the last character of the SHA1 :/\n\nNow with that resolved, the \"fetch branch; fetch commit\" also works just\nas before.\n\n> I'll take a look into the expected behavior, but if my assumptions are\n> correct, you should be able to just checkout the commit you want after\n> fetching the branch:\n> \n> git fetch \n> git checkout \n\nThis actually produces\nfatal: reference is not a tree: \n\nBut I can use the above dual fetch. Seems this problem was more between\nthe keyboard and chair. I am however glad to hear that literal SHA1s are\nbecoming fetchable.\n\nThanks for investigating,\n-- \nEero Aaltonen\n"}]}