4

I am having some personal git repos on my ownCloud. I can clone it from 2 ubuntu machines and a Windows PC by accessing ownClouds webdav url: http://myserver.a/remote.php/webdav/repos/repo.git

Recently I installed Arch Linux with git version 1.8.1.5 and it fails with this error message: fatal: http://myserver.a/remote.php/webdav/repos/repo.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?

I did add the post-update hook, eventually it works on my other machines. The servers error.log says 404 when git asks for ...info/refs?service...

The ubuntu git 1.7 requests the same url from the server. But after receiving an error code 404 it requests for .../info/refs HTTP/1.1 and succeeds with code 200.

So why does the newer git fail and how can I fix it?

namnor
  • 140
  • 1
  • 6

3 Answers3

5

The whole ?service=... thing is for git's smart HTTP support introduced in 1.6.6. It's much more efficient than the traditional HTTP support but requires a special CGI binary to be run on the web server and does not work with WebDAV.

IMO, in any non-broken WebDAV implementation, it should be ignored, but apparently ownCloud thinks it's part of the filename or something, and so produces an error. It might make sense to talk to the ownCloud developers about this.

In older versions, git fell back to a URL without that suffix, but that had its own problems. So, the second request was removed in 1.8.0 and a new option was introduced that you can use to turn off smart HTTP and use the old URL directly (this should fix the problem). It works like this, for instance:

GIT_SMART_HTTP=0 git fetch

If you never want to use smart HTTP (but be aware that it does work on Github and every other sane hosting site, and push won't work without it there), you can export that environment variable in your shell profile.

Details about the change at https://git.kernel.org/cgit/git/git.git/commit/?id=02572c2e3afcc200936260f48863447726212a7c.

Jan Krüger
  • 17,870
  • 3
  • 59
  • 51
0

I came across the same problem with pushing my Git repository to next cloud recently. I checked the contents of the repository and found that there was no such file info/refs there.

Researching that led me to this thread: can't clone git repos via http; info/refs not found

Executing the proposed command git update-server-info in the repository base directory created the missing file, and I did not get the 404 error anymore. So the query-string is not the problem here.

Unfortunately I get another error ("error: no DAV locking support on ..."), which is documented here https://help.nextcloud.com/t/webdav-lock-on-file-doesnt-work/21451 (with a link to a github-issue for the Nextcloud project).

Sadly, no Git repositories over WebDAV on Nextcloud yet.

bug.spencor
  • 1
0

This might be more robust now: "git clone"(man) from SHA256 repository by Git built with SHA-1 as the default hash algorithm over the dumb HTTP protocol did not correctly set up the resulting repository, which has been corrected with Git 2.32 (Q2 2021, 8 years later).

See commit 00bc839 (11 May 2021) by Eric Wong (ele828).
(Merged by Junio C Hamano -- gitster -- in commit bdff041, 20 May 2021)

remote-curl: fix clone on sha256 repos

Signed-off-by: Eric Wong
Acked-by: brian m. carlson

The remote-https process needs to update it's own instance of the_repository, when it sees an HTTP(S) remote is using sha256.
Without this, parse_oid_hex() fails to handle sha256 OIDs when it's eventually called by parse_fetch().

Tested with:

git clone https://yhbt.net/sha256test.git
GIT_SMART_HTTP=0 git clone https://yhbt.net/sha256test.git
(plain http:// also works)

Cloning the URL via git:// required no changes

Note: With Git 2.41 (Q2 2023), the documentation was misleading about the interaction between GIT_DEFAULT_HASH and "git clone"(man), which has been clarified to stress that the variable is to be ignored by the command.

See commit 5f0e37b (26 Apr 2023) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit b14a730, 15 May 2023)

doc: GIT_DEFAULT_HASH is and will be ignored during "clone"

The phrasing "is currently ignored" was prone to be misinterpreted as if we were wishing if it were honored.
Rephrase it to make it clear that the experimental variable will be ignored.

In the longer term, after/when we allow incremental/over-the-wire migration of the object-format, i.e.
cloning from an SHA-1 repository to create an SHA-256 repository (or vice versa) and fetching and pushing between them would bidirectionally convert the object format on the fly, it is likely that we would teach a new option "--object-format" to "git clone"(man) to say you would use whatever object format the origin uses by default, but this time, I am telling you to use this format on our side, doing on-the-fly object format conversion as needed".
So it is perfectly OK to ignore the settings of this experimental variable, even after such an extension happens that makes it necessary for us to have a way to create a new repository that uses different object format from the origin repository.

git now includes in its man page:

GIT_DEFAULT_HASH

This value is ignored when cloning and the setting of the remote repository is always used. The default is "sha1".

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250