Re: Behavior of 'git fetch' for commit hashes

[<eero.aaltonen@vaisala.com>]

On 20.06.2017 01:26, Jonathan Tan wrote:
> 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.

Yes. 2.13.1. I should stick to copy-pasting.

> 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.

I am now getting the same "unadvertised object" error. The "remote ref"
error it seems was due to missing the last character of the SHA1 :/

Now with that resolved, the "fetch branch; fetch commit" also works just
as before.

> I'll take a look into the expected behavior, but if my assumptions are
> correct, you should be able to just checkout the commit you want after
> fetching the branch:
> 
>   git fetch <forkUrl> <branch>
>   git checkout <sha1>

This actually produces
fatal: reference is not a tree: <sha1>

But I can use the above dual fetch. Seems this problem was more between
the keyboard and chair. I am however glad to hear that literal SHA1s are
becoming fetchable.

Thanks for investigating,
-- 
Eero Aaltonen