Comment by throwaway150

Comment by throwaway150 3 days ago

12 replies

View on Hacker News

> Additionally, GitHub seems to encourage a "push model" in which you are notified when a new event occurs in your project(s), but I don't want to work with that model. Instead, I prefer it to work as a "pull model", so I only get updates when I specifically look for them. This model would also allow me to easily work offline. Unfortunately, I see that the same push model has been copied to alternative forges.

Someone kind enough to explain this to me? What's the difference between push model and pull model? What about push model makes it difficult to work offline?

bayindirh 3 days ago

AFAIK, the author wants to work like how Source Hut and Linux kernel works: by e-mails.

When you're working with e-mails, you sync your relevant IMAP box to local, pulling all the proposed patches with it, hence the pull model.

Then you can work through the proposed changes offline, handle on your local copy and push the merged changes back online.

Reply View 9 replies
  • iamnothere 3 days ago

    I would love to see more projects use git-bug, which works very well for offline collaboration. All bug tracker info is stored in the repo itself. https://github.com/git-bug/git-bug

    It still needs work to match the capabilities of most source forges, but for small closed teams it already works very well.

    Reply View 0 replies
  • cxr 3 days ago

    Reminder that POP and IMAP are protocols, and nothing stops a code forge—or any other website—from exposing the internal messaging/notification system to users as a service on the standard IMAP ports; no one is ever required to set up a bridge/relay that sends outgoing messages to, say, the user's Fastmail/Runbox/Proton/whatever inbox. You can just let the user point their IMAP client to _your_ servers, authenticate with their username and password, and fetch the contents of notifications that way. You don't have to implement server-to-server federation typically associated with email (for incoming messages), and you don't have to worry about deliverability for outgoing mail.

    Reply View 0 replies
  • throwaway150 3 days ago

    All of this makes sense. Thank you for explaining. I don't think I understand the difference though.

    Like are they calling the "GitHub pull request" workflow as the push model? What is "push" about it though? I can download all the pull request patches to my local and work offline, can't I?

    Reply View 6 replies
    • bayindirh 3 days ago

      GitHub pull request pushes you a notification/e-mail to handle the merge, and you have to handle the pull request mostly online.

      I don't know how you can download the pull request as a set of patches and work offline, but you have to open a branch, merge the PR to that branch, test the things and merge that branch to relevant one.

      Or you have to download the forked repository, do your tests to see the change is relevant/stable whatnot and if it works, you can then merge the PR.

      ---

      edit: Looks like you can get the PR as a patch or diff, and is trivial, but you have to be online again to get it that way. So, getting your mails from your box is not enough, you have to get every PR as a diff, with a tool or manually. Then you have to organize them. e-mails are much more unified and simple way to handle all this.

      ---

      In either case, reviewing the changes is not possible when you're offline, plus the pings of the PRs is distracting, if your project is popular.

      Reply View 5 replies
      • lelandfe 3 days ago

        Seems like you found it, but for others: one of the easiest ways to get a PR's diff/patch is to just put .diff or .patch at the end of its URL. I use this all the time!

        Random PR example, https://github.com/microsoft/vscode/pull/280106 has a diff at https://github.com/microsoft/vscode/pull/280106.diff

        Another thing that surprises some is that GitHub's forks are actually just "magic" branches. I.e the commits on a fork exist in the original repo: https://github.com/microsoft/vscode/commit/8fc3d909ad0f90561...

        Reply View 2 replies
      • kijin 3 days ago

        You could set up a script that lives in the cloud (so you don't have to), receives PRs through webhooks, fetches any associated diff, and stores them in S3 for you to download later.

        Maybe another script to download them all at once, and apply each diff to its own own branch automatically.

        Almost everything about git and github/gitlab/etc. can be scripted. You don't have to do anything on their website if you're willing to pipe some text around the old way.

        Reply View 1 reply
        • bayindirh 3 days ago

          Why complicate the workflow when it can be solved with a simple e-mail?

          > Almost everything about git and github/gitlab/etc. can be scripted.

          Moving away from GitHub is more philosophical than technical at this point. I also left the site the day they took Copilot to production.

          Reply View 0 replies
johannes1234321 3 days ago

I would say it is time/life management: push tells you to do something now. In pull I check each Friday afternoon what's up in my hobby project and work on it for a few hours and then call it a day and be uninterrupted till next week.

Reply View 1 reply