From: Stefan Beller Date: Mon, 19 Jun 2017 15:50:34 GMT Subject: Re: Behavior of 'git fetch' for commit hashes Message-ID: In-Reply-To: <14e804c6-0798-8bbd-b182-66c3cd2b870c@vaisala.com> +cc Jonathan who did some work in the area. On Mon, Jun 19, 2017 at 5:09 AM, wrote: > Hello, > > I am seeing greatly different behavior for 'git fetch' commands on > version 2.7.4 and 2.13.1 when the argument to fetch is a commit hash. > > I am working on a custom Continuous Integration (CI) system. The > projects have dependencies that are simply fetched as repositories to a > project subdirectory. > > In order to prevent a race condition in updating branches, I want to > checkout the actual commit that was built in a previous job. > > Environment > =========== > Problem occurs with Git clients > - 2.7.4 > - 2.13.1 > > and Git server > - Atlassian Bitbucket v4.14.3 > - git version 2.12.0 > > > The problem can be reproduced as follows, with > - = URL to primary repository > - = URL to fork of the primary > - commit hash in a recent branch > > 1. git clone > 2. cd resulting_directory > 3. git fetch > > For version 2.7.4 > ================= > Git exits with exit code 1. > > However, if I first do 'git fetch ', then 'git fetch will > also work > > * branch -> FETCH_HEAD > > For version 2.13.3 > ================== > Git exits with exit code 128 and message > fatal: Couldn't find remote ref > > However, the workaround for descbibed abot for git version 2.7.4 no > longer works. The result is always > fatal: Couldn't find remote ref > > Desired result > ============== > Commit is in .git/FETCH_HEAD and can be checked out. > > > I want to checkout a specific commit without creating any extra named > remotes in the local git clone. > > Finally, > What is the expected behavior for 'git fetch' in this case? > Is there some other way I can achieve my goals? > > -- > Best regards, > Eero Aaltonen