Re: [SOLVED] Re: safe.directory does not work at all (git 2.39.5, 2.51.0)

From: Jeff King <peff@peff.net>
Date: Sep 15, 2025, 02:23 UTC
Message-ID: <20250915022301.GA593748@coredump.intra.peff.net>
In-Reply-To: <hbghuae56gm6ypox6q34mt4q6awoeb3itxsnmgpouycn7qodch@4pjsh24jhmqs>

On Sun, Sep 14, 2025 at 08:26:53PM +0200, Marc-Jano Knopp wrote:

Show 12 quoted lines

> > > 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