SWI-Prolog github repository ("bench" submodule) is currently borked

SWI-Prolog web site and services
1

The SWI-Prolog github repository is currently borked, more precisely, the bench submoduile seems to have a problem:

When trying to clone the submodules (I have added line breaks):

Cloning into 'tmp.V2HYd2beHX/swipl-devel_original/packages/zlib'...
fatal: remote error: upload-pack: 
not our ref 3fd9cb5301f3667b82d4c505c8ab60b59e855eec
e-band side-band-64k ofs-delta shallow deepen-since
deepen-not deepen-relative no-progress include-tag
multi_ack_detailed allow-tip-sha1-in-want
allow-reachable-sha1-in-want no-done 
symref=HEAD:refs/heads/master filter agent=git/github-gd72361c7e766
fatal: the remote end hung up unexpectedly
Fetched in submodule path 'bench', but it did not contain
3fd9cb5301f3667b82d4c505c8ab60b59e855eec. 
Direct fetching of that commit failed.
Error while cloning submodules in 'tmp.V2HYd2beHX/swipl-devel_original' -- exiting

See also this discussion: Why does git submodule update fail with “fatal: remote error: upload-pack: not our ref”?

Your superproject is asking for the hash ID [elided] in the Git repository you can clone from [some repo]. That commit simply does not exist in that repository, so it’s not in any clone you make either.

Do you know why your superproject lists this commit hash ID, even though it does not exist? (I certainly don’t.) You cannot get it from their Git, because they don’t have it. That’s what all these error messages are telling you.

The log says bench was changed this very morning, there was probably a problem at that point.

Shouldn’t happen, but, eh, computers, networking and all that.

1 Like
2

While Jan W. does check this site, the proper way to report this would be to open a GitHub issue for swipl-devl (https://github.com/SWI-Prolog/swipl-devel/issues). This way others who pull the code from GitHub and do not read this forum with see the issue. :smiley:

3

You are right. Reported now as https://github.com/SWI-Prolog/swipl-devel/issues/649

1 Like
4

Fixed. I appreciate the warning (should find a way to automate this check). I don’t care too much about where it is reported, but please avoid reporting twice :slight_smile:

1 Like
5

OK

I would like to give such post a new category or a subcategory; any suggestions before I create one.

6

We have SWI-Prolog web site and services for that. This one should be avoided by an automatic check.

7

I am lost on that statement.

8

It turns out adding this to ~/.gitconfig simply makes it impossible to push the master repo if one of the submodules is not pushed.

[push]
        recurseSubmodules = check

Added and this problem can no longer happen (well, unless I push from another machine on which I didn’t add this configuration :frowning: )

See https://stackoverflow.com/questions/25925414/how-to-prevent-unpushed-submodules-in-git

2 Likes