On Sun, Sep 14, 2025 at 08:26:53PM +0200, Marc-Jano Knopp wrote:
> > > Cloning into 'test'...
> > > fatal: detected dubious ownership in repository at '/git/main/test.git'
> > > To add an exception for this directory, call:
> > >
> > > git config --global --add safe.directory /git/main/test.git
> > > fatal: Could not read from remote repository.
> >
> > it is a little confusing, but the message comes from the git command
> > running in "my.server".
>
> D'oh! Is there a way for the layman to see if a message comes from the
> client or the server?
Usually we try to pass error messages from the server over the sideband
channel, where the client prefixes them with "remote:" before showing
them to the user. Or report them via ERR packets, in which case the
client says something like "remote error: foo". Like:
[this is an ERR packet; we are asking for a nonsense object id]
$ git fetch origin 0000000000000000000000000000000000000001
fatal: remote error: upload-pack: not our ref 0000000000000000000000000000000000000001
[this is stderr from a server sub-process routed over the err
sideband; I corrupted the server-side repo by removing one of
its packfiles]
$ git fetch $url
remote: error: Could not read 576053ed5ad378490974fabe97e4bd59633d2d1e
remote: fatal: Failed to traverse parents of commit a3287c454eb8f7b89d969e675768a6cfa258ad34
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
But for the error you're seeing, it is happening within upload-pack
itself (the server-side process handling the request), it happens before
we have even established that the client can handle sideband data, and
it is a die() call from within library code that does not know about ERR
packets. So the message goes to upload-pack's stderr on the server side,
and then ssh just passes it back. In fact, you are a little lucky to see
it at all; for a clone over http, it would just go to the webserver's
log (or maybe /dev/null).
I do agree it is not very friendly, so I'm laying this out to help
brainstorm ideas to make it better. Some possible directions I can think
of:
- could upload-pack install a die() handler that prints the message in
an ERR packet? I worry a little that older versions of Git would not
handle this great, as I don't think they were always prepared to see
an ERR packet at any point. OTOH, it is probably better than sending
nothing, which is what we do now.
- could the client-side process (git-clone or git-fetch) intercept
stderr from processes it spawns (ssh in this case, but also
git-upload-pack directly for local-system clones) and prefix it with
"remote:" or similar? That might help ssh and local system cases,
but other transports like http wouldn't benefit at all. Also, it
would probably involve forking off another process to consume
stderr.
I dunno. I don't love either of those that much. And while it could help
things in general, I think the main clue in this case is just that the
error message refers to '/git/main/test.git'. And that path is only
meaningful on the server, since the url was my.server:/git/main/test.git.
Knowing that the config advice is _also_ coming from the server is
probably the key subtle bit, though.
-Peff
