Re: how to use git with unreachable paths (namespaces, proc)?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-10-07 at 00:59:43, benaryorg wrote:
> Now as far as I can tell this is because git tries to resolve the
> symlinks in the path (/proc/$$/fd/3 is provided by the kernel as a
> symlink to ~/Documents/my_git_dir even though it doesn't exist in that
> hierarchy, yet you can access it, please don't ask me about the
> specifics of that) and then access them, which of course here doesn't
> work out. For the shared clone I understand why a path is necessary,
> considering that it needs to add the references to the new repository,
> however there seems to be no fallback for a scenario like this one.
> strace tells me that the call to `getcwd(2)` yields the path (outside
> the namespace) prefixed with "(unreachable)", which would explain why
> things fall apart (as this path is neither absolute nor accessible),
> or in other cases that git tries to walk the tree up (and by that I
> mean the tree outside the namespace) until it hits root, which I
> assume is its way to try and canonicalize the path, which here won't
> work either.
> 
> So my question is: is this a bug or intentional behaviour (given how
> particular git is around symlinks I can imagine either), and how can I
> work around this and make git perform basic operations such as status,
> archive, or alternatively get clone with `--shared` to work so that
> git can at least operate on a separate repository without all the
> prior objects being duplicated?
> Also note that this is absolutely not important to me, so if this is
> just something that git cannot handle in its current implementation
> that'd be fine by me, I just figured the chances that someone will
> reply to this with "why don't you use --ignore-path-reachability" are
> not negligible.

Git (and all compatible implementations) always canonicalize the path to
the `.git` directory (or bare repository) and the working tree (if any).
In your case, that won't work, because `getcwd(2)` returns a path that
doesn't work with `realpath(3)`, so Git is always going to fail.

The path canonicalization is required because otherwise it's very easy
to accidentally break the repository, and some old versions of Git had
problems when accessed from a path that contained a symlink[0], so it's
unlikely we'll add an option to skip it.

[0] Since I copy all of my home directory across when I get a new
machine, I actually have a broken repository from this era still today.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux