1. 34
  1.  

  2. 7

    Is there some more to the story here? I’m a bit confused as to what I’m looking at.

    1. 25

      See the comments below the commit:

      As far as I know, all forks of a Github repo are set up to use a sort of a “super-repository” containing all objects from all other forks. The actual forked repositories are thin repacks with alternates set to point to that “super-repo.” This allows for huge savings in disk space, because git is able to deduplicate a lot of redundant data and create efficient deltas for most commits. However, this also means that you can fork a repo, add a nasty commit to it like this one, and wait till the “super-repo” fetches it. After that happens, you are able to refer to it from any of the other forks as is demonstrated here.

      I missed that too the first time I clicked on the link.

      1. 4

        I wonder how long it will take for that comment to get lost in a sea of flotsam.

        Thanks for clearing it up for me. Since I don’t use Github, this comment is more or less the story.

        1. 4

          GitHub renders comments in chronological order, so it’s not possible for them to be “lost in a sea of flotsam” like they can be in Reddit and its clones.

      2. 15

        Spotted originally here.

        Hey @github did I just get a rootkit committed into Linux, or do you have a bug in your URLs where people can make it look like code is committed to a project that they do not have commit access to?

        https://github.com/torvalds/linux/commit/b4061a10fc29010a610ff2b5b20160d7335e69bf

        Linus’ response, copied in the comments below the commit:

        Response from Linus:

        Misleading URL. Not in my tree, just using github to make it look like it.

        These is no actual commit ID b4061a1 in my tree, but when you pass github a SHA1, it doesn’t do any reachability analysis whether that actually exists in the named tree, so it uses a completely unrelated commit from somebody elses tree on github.

        1. 3

          Its just the gihub UI, you can look at commits from forks through a url/ui that belongs to the “main” repository.

          I think examples like this pop up every other year, but I can’t find any references.

        2. 4

          I think the title is somewhat misleading, AFAIK GiHub does this since a very long time (if not the very beginning).

          1. -1

            They are in the tree, just not in the master branch…

            1. 3

              In someone else’s fork, which is stored as part of the same repo to save disk space…