Re: Behavior of 'git fetch' for commit hashes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> On Mon, 19 Jun 2017 12:09:28 +0000
> <eero.aaltonen@xxxxxxxxxxx> 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.

> > 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@xxxxxxxxxxxxxx/



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux