1. 66
  1.  

  2. 20

    Appreciated the write up, including the mention of git’s request pull option

    However I found the underlying tone of GitHub being an ensnaring agent of malicious intent a little distracting.

    More words spent on the bazaar model and furthering git’s proper use in support of that model (clone, add remote, fetch?) will always be appreciated.

    1. 2

      Github is a capitalist entity and ofc it doesn’t care about anything else but profits

    2. 12

      This is a very well-written article. I really dislike GitHub and hate working with it. Especially for small changes, it is very cumbersome to open a pull-request and having to deal with all the kitchen-sinking. I much prefer the way to just send a patch to a mailing list, where it can be discussed and merged.

      1. 9

        Isn’t code browsing of the pull request on the web much more convenient than applying the latch locally? I’ve used both GitHub and gitlab pull request flows on a lot of commercial products, and it would’ve been a pain to go through the email process.

        TBH, I can’t remember when was the last time I used email aside from automatic notifications and some of the headhunters (most already prefer linkedin and messengers anyway).

        1. 20

          Here’s a video which demonstrates the email-based workflow using aerc. This isn’t quite ready for mass consumption yet, so I’d appreciate if if you didn’t repost it elsewhere:

          https://yukari.sr.ht/aerc-intro.webm

          1. 5

            Wow… I’ve known for years that the git+email workflow was behind a more distributed model for open source development, but all my experience is on github and so making the switch has felt too-difficult. This article and this video together make me feel compelled (inspired?) to give it a go. aerc looks amazing.

            1. 6

              Consider giving sourcehut a try, too :)

              1. 3

                Thanks for making sourcehut!

                I took a look a few times but I can’t seem to find any obvious documentation to setup and configure it. I fully acknowledge that I may be blind.

                1. 5

                  I assume you don’t want to use the hosted version? If you want to install it yourself, instructions are here:

                  https://man.sr.ht/installation.md

                  There are only a small handful of installations in the wild, so you might run into a few bumps. Shoot an email to ~sircmpwn/sr.ht-discuss@lists.sr.ht or join #sr.ht on irc.freenode.net if you run into issues.

            2. 2

              Having tried to record a few casts like this, I know how hard it is to do a take with few typos or stumbling on words. Well done.

              The idea of using a terminal emulator in the client is a cool idea :). I usually use either VS code or sublime text, though this gives me an idea for a terminal ‘editor’ that just forwards to a gui editor, but displays either a message, or mirrors the file contents.

              1. 2

                I can’t do this either :) this is edited down from 10 minutes of footage.

              2. 1

                I have done the same thing albeit differently in my client[0]! I don’t have any casts handy, but the whole patch apply, test, HEAD reset, branch checkout/creation is handled by the client. I’ve also started patchwork integration.

                [0] https://meli.delivery/ shameful plug, because I keep posting only about this lately. Guess I’m too absorbed in it.

                1. 1

                  Ah, it’s this! I filed an issue because there doesn’t appear to be any public source, and I wanted to try it.

              3. 1

                I think locally you can script your workflow to make it as easy as you want. However not many people take the time to do this (I haven’t either).

              4. 2

                This is a very well-written article. I really dislike GitHub and hate working with it. Especially for small changes, it is very cumbersome to open a pull-request and having to deal with all the kitchen-sinking. I much prefer the way to just send a patch to a mailing list, where it can be discussed and merged.

                I think a bridge would be nice, where emails sent can become pull requests with no effort or pointless github ‘forks’.

                1. 2

                  Worse yet, barely anyone remembers that Git is still a “real” distributed version control system and that “request pull” exists - and, yes, you didn’t mean to say “pull request”. The fact that GitHub called their functionality a “pull request” is somewhat annoying as well.

                  Edit: I’m glad the article mentions this in the P.S. section - and I should really read the entire article before I comment.

                2. 9

                  Another great writeup from Drew. I remember when I was learning how to work with Git in 2011, and trying to explain the model to my proprietary .NET world coworkers (at this time Microsoft had not yet embraced open source and we all used TFS for our centralized source control) didn’t go well.

                  Now, that same community uses terms like ‘fork’ and ‘pull request’ in exactly the fashion Drew describes here - for centralized control systems (be it on Github or Azure Devops).

                  1. 9

                    it’s worth noting that github is still git. You can still use the patch/email method (which is largely how clojure works, though with jira instead of a mailing list). I personally find it more convenient to use PRs than messing with email.

                    1. 20

                      I’m confused by this post.

                      A github fork is a convenient UI over git’s branches. You create your own personal copy of the repository and the github platform does some configuration that allows you to use their nice UI for allowing them to merge your branch/changes even if you don’t have write access to the project. They have a nice UI for doing the commentary and reviews etc.

                      Nothing says you have to use this. You can do bare git stuff, ask for write permissions, push your changes etc. etc.

                      This post is complaining that github adds a value - for most users - by giving them a easy to use UI over git.

                      1. 14

                        The article is mostly about how github has overloaded the term ‘fork’, giving it the same meaning as a traditional personal repo copy. Forking a project, as the article mentions, is taking it and giving it new life as something else, without necessarily contributing changes back to the original repo (article gives the example of the ffmpeg –> libva forking).

                        Github is taking well-established terminology and giving it new meaning in their proprietary platform, which causes confusion.

                        1. 9

                          The article is mostly about how github has overloaded the term ‘fork’, giving it the same meaning as a traditional personal repo copy.

                          It’s somewhat difficult to take this complaint seriously considering the article then proceeds to do the exact same thing by using the term “branch” to mean “clone of a git repo” instead of the already existing meaning of “branch within a git repo”.

                          Either pedantry over terminology is a big deal or it isn’t (my take is that it really isn’t), but the author needs to pick a lane.

                          1. 3

                            Your application of branch is too specific and tied to the idea of a canonical upstream repository. Cloning is the process of creating a local branch which mirrors a remote branch. The end result is still a branch.

                            1. 9

                              Your application of branch is too specific and tied to the idea of a canonical upstream repository.

                              Not at all, it’s merely tied to the semantics of git, the DVCS under discussion here.

                              Cloning is the process of creating a local branch which mirrors a remote branch.

                              Cloning creates a local copy of a remote repository and (typically, unless you do some things to restrict it) all branches within it. Creating a local branch which mirrors a remote branch is not a clone operation, it’s a git fetch —track.

                              It’s incorrect to describe a fetch as a clone. It’s incorrect to describe a repository as a branch. These are all distinct concepts in git, with different semantics, regardless of whether or not your development model involves a canonical upstream or not.

                              1. 2

                                I’m definitely simplifying things a lot, and I appreciate your clarifications. But my point is that you end up with your own “master” branch, which is discrete from the other branch. The repo is just a container for that branch, no matter where you have it pushed. The key distinction between your repo and the other repo is the branch you’re doing your work on. Thus, I think branch is a valid term to use here.

                          2. 13

                            Which possibly is an over load of “forking processes”, which possibly is a overload of the term “fork” meaning a thing with multiple prongs. “clone-ing” a repository relates to “A clone” of something and so on. Language is malleable.

                            Github forks allow you to neatly merge back to what you forked from. Again, you don’t need to use this. I think this is just a bad argument.

                          3. 9

                            I think it’s easier to understand the implicit criticism by wondering about how Github would have been if it wasn’t based around forking a project to contribute to it. Currently the data that is used to create a pull request – in addition to the reference to which you want to contribute changes – is the name of your personal fork, and of the branch you want to send.

                            Now if forks were not pervasive, how would people be able to contribute to projects on github? Well, either they would have to indicate the URL of a full git somewhere (and a branch name), or they would submit to github a series of patch (by sending an email, or by uploading git format-patch files, etc.).

                            Those two models are not much harder to implement than the current forking model, and/but they immediately make github a partially federated platform, making it easy to contribute to a github-hosted project without yourself being on github or hosting your personal working copy on github.

                            You can see how that is not much less convenient for users, and how it makes it much easiers for users to migrate to another platform.

                            Personally I’m not at all surprised that github is not interested in supporting these less-centralized workflows, but I am a bit disappointed that Gitlab has not yet invested much effort in supporting them. Contrarily to github, there are many instances of Gitlab (the free version) around, and merge-requests-across-instances would be directly useful to me today. In fact, there are some instances that I avoid using specifically because they restrict account creation (or creation of new projects for untrusted users), which kills collaboration in a fork-centric model. (See gitlab issues #4013, #260, patch by email #40830).

                            1. 8

                              Now if forks were not pervasive, how would people be able to contribute to projects on github? Well, either they would have to indicate the URL of a full git somewhere (and a branch name), or they would submit to github a series of patch (by sending an email, or by uploading git format-patch files, etc.).

                              But “Github forks” being pervasive does absolutely nothing to prevent you from continuing to do just this?

                              Unless the complaint here is “if I email a patch to a maintainer, they complain that it’s a PITA to deal with and ask me to just submit a PR”, in which case…

                              You can see how that is not much less convenient for users

                              I’ve worked in both models, I strongly disagree.

                              Federation is great. Emailing patches around sucks a ton.

                              1. 2

                                “matt” matt@lobste.rs writes:

                                Emailing patches around sucks a ton.

                                Having a fast tagging system like notmuch helps a lot, and doesn’t take much time to setup.

                                1. 2

                                  Emailing patches around sucks a ton.

                                  I agree. However, after thinking about it a bit, @gasche’s comment made me wonder about a word where github supplied a “git-format-patch-pr” – similar to emailing patches, but which instead uploaded patches to github from a local branch into some ephemeral PR specific location. All this instead of having to create a fork and open a PR.

                                  1. 4

                                    The Phabricator workflow is pretty similar to what you’re describing: you can use arc to upload patches from a local branch. Or just paste diff output into a web form without even committing anything :D

                                    1. 1

                                      I like this workflow so much, but I couldn’t convince my co-workers of its qualities, because they (understandably) get uneasy about the fact that patches don’t have a clear “target” – and they can mean different things depending on what they are applied to. (If anyone has a suggestion for a solution for this, please contact me.)

                                      (So instead they keep using Bitbucket and adopt all kinds of terrible practises for the only reason that doing the right thing is made highly inconvenient by bitbucket.)

                                    2. 2

                                      Emailing patches around sucks a ton.

                                      I agree. However, after thinking about it a bit, @gasche’s comment made me wonder about a word where github supplied a “git-format-patch-pr” – similar to emailing patched, but which instead uploaded patches to github from a local branch into some ephemeral PR specific location.

                                      I wonder if it would be considered rude to simply attach a patch to the relevant github issue..? Or link to a patch stored on a paste service like ix.io? You can add to github issues over email, so with this method you could sort-of submit patches over email, bypassing the whole PR interface.

                                      1. 2

                                        Worth noting that, while it doesn’t stop you from needing to make a fork, you can retrieve a .diff or .patch from any comparison: https://github.com/microsoft/VFSForGit/compare/features/linuxprototype...github:linux-gvfs-provider.patch

                                  2. 5

                                    A github fork is a convenient UI over git’s branches

                                    Not in my experience. It usually consists of:

                                    • Patch my clone
                                    • Try to push
                                    • Get permission denied, since I forgot that I don’t “own” the remote
                                    • Go to the GitHub page
                                    • “Fork” the repo
                                    • Edit .git/config, or try to remember what the git remote commands are, to change origin to my “fork” (I usually keep the previous remote as upstream, since my “fork” will inevitably fall behind and need regular pulling and pushing)
                                    • Try to push again
                                    • Go back to GitHub and use the “pull request” UI
                                    • Add a comment to the pull request that links it back to the “issue” that caused me to make the change
                                    • Try to keep track of both threads of conversation, until the patch gets merged
                                    • Have a small existential crisis as I debate whether to delete this “fork”, to cut down the hundreds of repos I have to wade through; or whether I should be a good Netizen and preserve the URLs.

                                    Phew!

                                    1. 3

                                      Afaik you don’t have to change the upstream, you can just say git push <alternate upstream>. I might be wrong about that, though; might be confusing it with git pull. Also, afaik deleting the ‘fork’ is standard practice; you aren’t really contributing to linkrot that way, because you’re not erasing any content, and no one is linking to such a fork.

                                      To be clear, I still think the github pull request ui is awful, but ^^^ is my understanding of how it works.

                                      1. 3

                                        Indeed, git push takes either a URL or remote name as its first numbered argument. Sometimes if I need to make a quick push to a remote I don’t use commonly, I’ll just detach HEAD, make commit/s, then git push git@wherever:whatever.git HEAD:remote-branch.

                                  3. 3

                                    @SirCmpwn I understand your argument. Github came up with a centralized UI - you claim that it is bad. What is your proposal (besides email)?

                                    1. 2

                                      My proposal is email.

                                      1. 1

                                        I think the argument here is that email is likely the most bazaar-esque way to contribute to a software project, and coincidently, how git was optimized to be used.

                                      2. 3

                                        I find it almost poetic that Microsoft ended up with Github in their court, given the position MS has maintained in the cathedral/bazaar debate for decades. Aside from the cruel but inevitable betrayal of their closed-source origins, I can’t imagine a better owner of the Our Lady of Open Source website, Github.

                                        Sarcasm aside, Github did introduce a LOT of people to the concept of open source, even if you don’t agree with their distribution methods. I love ESR as much as any card carrying FOSS advocate, but the software revolution was not going to happen on mailing lists.

                                        1. 4

                                          GitHub destroyed the distributed aspect of a DVCS like git. There has been good attempts at creating distributed bug trackers, wikis, code review tools built on top of git. bugs-everywhere is an example.

                                          Yet, GitHub refused to support such projects and that practically killed them.

                                          1. 5

                                            “Yet, GitHub refused to support such projects and that practically killed them.”

                                            A good strategy if they were hypothetically aiming for a highly-profitable acquisition by a company that specializes in centralized services with max lockin. ;)

                                            1. 2

                                              A good strategy if they were hypothetically aiming for a highly-profitable acquisition by a company that specializes in centralized services with max lockin. ;)

                                              Yep, I’m sure that’s what the founders intended when they designed most of these features a decade ago.

                                              1. 2

                                                I believe acquisition is a fairly common end goal for VC-backed startups.

                                                1. 1

                                                  What you just said is very different to what Nick just said, which is what I was replying to. They also weren’t VC-backed when most of the referred-to features were designed.

                                            2. 3

                                              bugs-everywhere is (a little) well known, but I couldn’t get it to work (some dependency was broken). It also seemed rather over-complicated.

                                              I then tried Artemis and found it works really nicely. Since it stores issues as standard mbox directories, I can compose/comment-on them using Emacs’s standard email mode; and I can render them to HTML using mhonarc :)