1. 20

Example use can be seen with Tiny C Compiler’s repo.

  1.  

  2. 5

    I remember someone here who was writing about Github’s whole “fork” model being totally busted cuz the activation energy is like “fork this repo, send in one patch, then send it back” instead of just “write the patch and give it in”. I wonder if widespread adoption of this for Git would enable that kind of workflow over on GH & co.

    (I mean there’s always email patches too I guess… would be cool if GH supported that as well)

    1. 13

      The friction is still lower than hoping your email/list didn’t get mangled.

      1. 2

        I think it would have been better if Git made sure that attaching patches as Email attachments was also supported by the regular tooling. The entire issue with mangled patch messages stems from the assumption of non-technical clients that plain-text doesn’t have to maintain a structure.

      2. 4

        For simple one-file changes, Github’s web UI works fine. You click “edit” on a file, do your changes, then at the bottom there’s a button that allows you to create a PR with that change as its only commit. Github will fork the repository in the background for you.

        1. 2

          Yeah, that wasn’t around for the first few years of GitHub’s existence, but it definitely does help with the rate of casual contributions.

      3. 3

        It may be low profile which certainly adjusts risk assessment, but this Wikipedia/Wiki-like model for tcc has seemed to work well for over 10 years now, i.e. about as long as Github has been around (or git for that matter).

        1. 7

          I don’t know to what extent kids this days see Wikipedia as obvious, but I remember how when I first stumbled upon this idea of wiki, my mind was completely “oh shit, this is crazy, this can’t possibly be working.. yet, here it is?!?”, including the guilty pleasure of being able to edit someone else’s website with no strings attached… now that we know it does work, transplanting the idea to vcs seems to me similarly crazy, genius and exciting!

          1. 4

            Oh sure. Your exceitement is understandable. It is kind of natural, though – Wikis usually use version control as a way to make repair from mistakes/vandalism easy.

            Why, in some alternate timeline/history, VCs might have been invented for Wikis before for source code… :-) Even in our own timeline, automatic management of document versions in word processors may have pre-dated RCS. diff certainly did and for like over a decade the Linux kernel worked off of just diff/patch. So, maybe this happened for VC in our own timeline, but only got really fancy for devs into fancy tools.

            It is a pleasant surprise that mob revision can/does mostly work, as I think Jimmy Wales (founder of Wikipedia) continues to say. His first real-life version was purportedly (EDIT: a slightly upscale version of) yellow Post-It notes on a paper encyclopedia - the OG diff/patch. ;-)

            1. 4

              One difference I noticed long ago between git and wikis’ history, is that when writing text, I don’t seem to need nor want the extra step of commits spanning multiple files. This is rather curious to me, and also showed up when I tried to write an editor with versioning/history support; I started thinking to maybe “just” reuse git, but it quickly begun to feel like a major impedance mismatch to me.

        2. 2

          I know of at least one person who uses a similar development model. To send a patch to one of their projects, you can just push to a branch named patch_XXX with the git protocol, where XXX is a topic name.

          It’s not at all a bad way to live. If you already understand git, then you understand this model implicitly. No forking repos, sending PRs, etc etc.

          I’ve been thinking about how to build a minimalist code forge around this concept, perhaps using GNUPG to assure the authenticity of commits and pushes.