On Sun, Jun 16, 2024, at 4:39 PM, David C. Rankin wrote:

On 6/16/24 05:30, Guus Snijders wrote:

> Have you tried using http:david instead?

> And make sure the files are group-writable.

> I haven't tested this, but this seems to answer all the mentioned constraints.

Unfortunately, yes, I've tried every combination of user:group ownership

and it is really unfortunate that git won't server https unless the

directories are 'owned' by http. I've even tried adding myself to the http

Why I can't chmod 0775 repodir.git and then use david:http is indeed

stange, but git requires http:dontcare to server https.

Of course ssh requires david:dontcare to server git over ssh.

I'll have to try Ryan's binfs work around and see if I can make something

like that work. It's just wild that git doesn't have a published fix for this

after the security change.

github does something. I can pull over https and ssh still works there. It

may be worth opening an issue with git to see how they feel this catch 22

should be handled for locally hosted servers. If I find a fix, I'll report back.

David C. Rankin, J.D.,P.E.

github does something. I can pull over https and ssh still works there.

I highly doubt GitHub uses standard Git in their backend at all. Your git repository is probably sitting in chunks somewhere in a highly distributed database with lots of indexing and whatnot added on top; you're not just connecting to a server and pulling the repo directly off disk somewhere. It may have started off using standard git, but I'll eat my hat if it still is.

I had the "pleasure" of using/administering TFS (Microsoft Team Foundation Server) 8+ years ago when they introduced Git support; I spent a while trying to figure out where they stored the git repositories until I found that everything was in the database, just like everything else in TFS. They just implemented a git-compatible API of sorts where Git thinks it's talking to a regular git server.