On Mon, Dec 12, 2022 at 04:44:49PM +0000, mark.yagnatinsky@xxxxxxxxxxxx wrote: > Never mind, I see, feature exists but server needs to allow it. Sigh. There are good reasons for remote servers to not allow this by default. Imagine the following scenario: Repo 1: officialrepo.git -- official project repository Repo 2: forkedrepo.git -- a random fork by someone Frequently, these repositories will use a common object storage backend, which allows saving a LOT of space on the remote server. So, on the backend these repositories will be organized as: Repo 0: sharedrepo.git Repo 1: officialrepo.git (with alternates to sharedrepo.git) Repo 2: forkedrepo.git (with alternates to sharedrepo.git) So, if a random developer pushes commit abcde into forkedrepo.git and the backend server pulls that object into sharedrepo.git, you are now able to "see" commit abcde from officialrepo.git. It's just a "loose object" and if you clone officialrepo.git, that object won't be in it, because it's not connected to any of the heads or tags. This situation is frequently abused for silly reasons like making it appear as if Linus committed something that he actually didn't: https://github.com/torvalds/linux/blob/ac632c504d0b881d7cfb44e3fdde3ec30eb548d9/Makefile#L6 For this reason, Github prints that big warning at the top to tell you that what you are viewing isn't actually part of linux.git. However, there's no way to print this warning if you issue "git clone", so if this feature were to be allowed by default, it would make it easy for someone to trick you into cloning malicious commits by making it look like you're cloning an official repository. I go into it in some detail here: https://people.kernel.org/monsieuricon/cross-fork-object-sharing-in-git-is-not-a-bug Best regards, Konstantin
