← Back to context

Comment by TazeTSchnitzel

2 years ago

This is not new. Many people have noticed this before, e.g. https://hikari.noyu.me/blog/2020-05-05-github-private-repos-...

9 comments

TazeTSchnitzel

Reply
majorchord  2 years ago

No but I think attention should still be raised to it in the hopes they will fix it. The squeaky wheel gets the grease.

https://xkcd.com/1053

  • dwaite  2 years ago

    First step would be to have them acknowledge a documented behavior which was part of their original design 16 years ago, is something that needs to be fixed.

    As someone who has used git and GitHub extensively over that time, none of what the author documented was a surprise to me.

    However, I also remember when people were trained to do a "Save As" when preparing a final Word document or Powerpoint for sharing with a third party. That certainly bit enough business users that Microsoft eventually changed the default behavior.

  • dncornholio  2 years ago

    There's nothing to be fixed though.

    • hnbad  2 years ago

      If people are surprised by this - and clearly a non-trivial number of people are - then even if the behavior works as intended it should be indicated in the UI at critical points.

      GitHub is not simply a UI to actual git repositories it hosts. It also carries a lot of data that is not stored in the repository itself. The UI deliberately blends the two types of interactions. There's no such thing as "creating a pull request" in git, for example.

      It's not at all unreasonable for a user to assume "forking" merely creates a copy with an upstream origin. Read through the steps again:

          1. You fork a public repository
    2. You commit code to your fork
    3. You delete your fork

      Note that from a user's point of view, they only committed code to their "copy" of the repository, i.e. their own repository. They never pushed it upstream or created a pull request that references it. That abstraction is clearly wrong if you look at what actually happens but it's not difficult to see why a user might think this way, especially given that "a fork" often simply means "a copy", i.e. something standalone that then goes on to diverge from its origins (e.g. "Edge is a fork of Chromium" or "MariaDB is a fork of MySQL").

      Of course the mistake is that the fork is not a copy. The fork isn't a fork (i.e. a separate copy that shares the original's history), it's a view of the original repository with its own refs. The commits are added to the same repository, only the refs that reference them aren't. This makes sense architecturally but it means most metaphors and analogies people likely bring to the table break down because they assume a fork is a copy, not a collection of refs layered over a shared repository of commits - after all "allowing stranges to add commits to the repository" is what PRs are for. Except of course that's not what PRs do then, PRs actually allow strangers to add references to commits to your branches.

  • Waterluvian  2 years ago

    I love this xkcd.

    We all need to embrace: Nobody has ever been impressed that you already knew something. When people share a discovery with you, it’s not about you. It’s about them and their joy of discovery. They want to share that joy with you.

    • nox101  2 years ago

      If they're sharing the joy of discovery that's great. Lots of people though are gloating. "Haha, you're stupid, you didn't know X and I did". In other words, they're the ones not being charitable by assuming you don't already know X.

      Trying to think of an example it usually goes something like

      A: We should do X

      B: No. See this document (the sharing part)

      A: I wrote that document and I'm telling you we should do X (the "I already knew this" part)