Re: Behavior of 'git fetch' for commit hashes

[Stefan Beller <sbeller@google.com>]

+cc Jonathan who did some work in the area.

On Mon, Jun 19, 2017 at 5:09 AM,  <eero.aaltonen@vaisala.com> 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
> - <authoritativeUrl> = URL to primary repository
> - <forkUrl> = URL to fork of the primary
> - <sha1> commit hash in a recent branch
>
> 1. git clone <authoritativeUrl>
> 2. cd resulting_directory
> 3. git fetch <forkUrl> <sha1>
>
> For version 2.7.4
> =================
> Git exits with exit code 1.
>
> However, if I first do 'git fetch <branch>', then 'git fetch <sha1> will
> also work
>
>  * branch   <sha1> -> 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