Re: Behavior of 'git fetch' for commit hashes

From: Jonathan Tan <jonathantanmy@google.com>
Date: Jun 19, 2017, 22:26 UTC
Message-ID: <20170619152658.4559bce4@twelve2.svl.corp.google.com>
In-Reply-To: <20170619104936.706eff69@twelve2.svl.corp.google.com>

On Mon, 19 Jun 2017 10:49:36 -0700 Jonathan Tan <jonathantanmy@google.com> wrote:

> On Mon, 19 Jun 2017 12:09:28 +0000
> <eero.aaltonen@vaisala.com> wrote:
> 
> > For version 2.13.3

Firstly, exactly which version of Git doesn't work? I'm assuming 2.13.1 (as written elsewhere in your e-mail), since 2.13.3 doesn't exist.

Show 5 quoted lines

> > 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
> 
> I'll take a look into this.

I tried to reproduce with this script, but it seems to pass even at 2.13.1:

    #!/bin/bash
    rm -rf ~/tmp/x &&
    make --quiet &&
    ./git init ~/tmp/x &&
    ./git -C ~/tmp/x fetch --quiet ~/gitpristine/git master:foo &&
    ./git -C ~/tmp/x fetch ~/gitpristine/git "$(git -C ~/gitpristine/git rev-parse master^)"
    exit $?

Commenting out the first fetch line produces, as expected:

    error: Server does not allow request for unadvertised object <hash>

And I have not seen the "fatal: Couldn't find remote ref" error you describe.

As Stefan alluded to in his earlier e-mail [1], I made a change recently to how "git fetch" handles literal SHA-1s in commit fdb69d3 ("fetch-pack: always allow fetching of literal SHA1s", 2017-05-15). In this case, I don't think that's the cause of this issue (since that change, if anything, makes things more permissive, not less) but that might be a point of interest in an investigation.

[1] https://public-inbox.org/git/CAGZ79kbFeptKOfpaZ23yK=Zw9mJ0_evqPstHKkD1HSCaP_pC5g@mail.gmail.com/