8 ms·

> It doesn't include pull requests, when cloning from github, though. Because GitHub pull requests are a proprietary, centralized, cloud-dependent reimplementa

> It doesn't include pull requests, when cloning from github, though. Because GitHub pull requests are a proprietary, centralized, cloud-dependent reimplementation of `git request-pull`. How the "free software" world slid head first into a proprietary cloud-based "open source" world still boils my blood. Congrats, Microsoft loves and owns it all, isn't that what what we always wanted?

seba_dos1 11mo ago
They are available as refs on the remote to pull though, they just aren't listed so don't end up mirrored either.
- masklinn 11mo ago
  They are listed tho. You can very much see them in info/refs.
  - seba_dos1 11mo ago
    My bad! I got misled by grandparent - they are in fact mirrored with "git clone --mirror" as well.
velcrovan 11mo ago
When this kind of “sliding” happens it’s usually because the base implementation was missing functionality. Turns out CLI interfaces by themselves are (from a usability perspective) incomplete for the kind of collaboration git was designed to facilitate.
- Certhas 11mo ago
  In another post discussion, someone suggested git as an alternative to overleaf, a Google Docs for latex... I guess there are plenty of people with blind spots for things that are technically possible, and usabel to experts, and UI that actually empowers much broader classes of users to wield the feature.
  - pastel8739 11mo ago
    If you actually use the live collaboration features of overleaf, sure, it’s not a replacement. But lots of people use overleaf to write latex by themselves. The experience is just so much worse than developing locally and tracking changes with git.
  - cozzyd 11mo ago
    Is the joke that overleaf has decent git integration?
    - jdingel 11mo ago
      Overleaf doesn't support branches, etc.
      - cozzyd 11mo ago
        That's true, but at least it's possible to use via git. Great for working during a flight etc
- derefr 11mo ago
  > Turns out CLI interfaces by themselves are (from a usability perspective) incomplete for the kind of collaboration git was designed to facilitate. git was designed to facilitate the collaboration scheme of the Linux Kernel Mailing List, which is, as you might guess... a mailing list. Rather than a pull-request (which tries to repurpose git's branching infrastructure to support collaboration), the intended unit of in-the-large contribution / collaboration in git is supposed to be the patch. The patch contribution workflow is entirely CLI-based... if you use a CLI mail client (like Linus Torvalds did at the time git was designed.) The core "technology" of this is, on the contributor side: 1. "trailer" fields on commits (for things like `Fixes`, `Link`, `Reported-By`, etc) 2. `git format-patch`, with flags like `--cover-letter` (this is where the thing you'd think of as the "PR description" goes), `--reroll-count`, etc. 3. a codebase-specific script like Linux's `./scripts/get_maintainer.pl`, to parse out (from source-file-embedded headers) the set of people to notify explicitly about the patch — this is analogous to a PR's concept of "Assignees" + "Reviewers" 4. `git send-email`, feeding in the patch-series generated in step 2, and targeting the recipients list from step 3. (This sends out a separate email for each patch in the series, but in such a way that the messages get threaded to appear as a single conversation thread in modern email clients.) And on the maintainer side: 5. `s ~/patches/patch-foo.mbox` (i.e. a command in a CLI email client like mutt(1), in the context of the patch-series thread, to save the thread to an .mbox file) 6. `git am -3 --scissors ~/patches/patch-foo.mbox` to split the patch-series mbox file back into individual patches, convert them back into an annotated commit-series, and build that into a topic branch for testing and merging. Subsystem maintainers, meanwhile, didn't use patches to get topic branches "upstream" [= in Linus's git repo]. Linus just had the subsystem maintainers as git-remotes, and then, when nudged, fetched their integration branches, reviewed them, and merged them, with any communication about this occurring informally out-of-band. In other words, the patch flow was for low-trust collaboration, while direct fetch was for high-trust collaboration. Interestingly, in the LKML context, `git request-pull` is simply a formalization of the high-trust collaboration workflow (specifically, the out-of-band "hey, fetch my branches and review them" nudge email). It's not used for contribution, only integration; and it doesn't really do anything you can't do with an email — its only real advantages are in keeping the history of those requests within the repo itself, and for forcing requests to be specified in terms of exact git refs to prevent any confusion.
paulddraper 11mo ago
Having a web interface was really appreciated by users, it would seem.
- jasode 11mo ago
  >Having a web interface It's not the interface, it's the web hosting. People want a free destination server that's up 24/7 to store their repository. If it was only the web interface, people could locally install GitLab or Gitea to get a web browser UI. (Or use whatever modern IDE code editor to have a GUI instead of a CLI for git commands.) But doing that still doesn't solve what GitHub solves: a public server to host the files, issue tracking, etc. Before git & Github, people put source code for public access on SourceForge and CodeProject. The reason was the same: a zero-cost way to share code with everybody.
  - udev4096 11mo ago
    GH is essentially an unlimited storage space. There are countless scripts which makes it possible to even use it as an unlimited mounted storage
    - FpUser 11mo ago
      And then one day orange gets pissed of at yet another country and it (the repo) is gone
      - wiz21c 11mo ago
        orange ?
        deleted 11mo ago
        [deleted]
        kevin_thibedeau 11mo ago
        The convicted felon.
udev4096 11mo ago
It still blows my mind how git has lost it's original ideas of decentralized development because of github and how github, a for-profit - centralized - close-sourced forge, became the center for lots of important open source projects. We need radicle, forgejo, gitea to catch up even more!
- seunosewa 11mo ago
  Once they killed mercurial on bitbucket, it was over.
- afavour 11mo ago
  I don’t think it’s really that surprising. git didn’t become popular because it was decentralised, it just happened to be. So it stands to reason that part doesn’t get emphasised a ton.
  - int_19h 11mo ago
    It did become popular because it was decentralized, but the specific features that this enabled were less about not depending on a central server, and more about being able to work with the same repo locally with ease without having to be online for most operations (as was the case with Subversion etc). Git lets me have a complete local copy of the source with all the history, branches etc in it, so anything that doesn't require looking at the issues can be done offline if you did a sync recently. The other big point was local branches. Before DVCS, the concept of a "local branch" was generally not a thing. But now you could suddenly create a branch for each separate issue and easily switch between them while isolating unrelated changes.
- lisbbb 11mo ago
  I once worked at a smaller company that didn't want to shell out for github and we just hosted repos on some VM and used the ssh method. It worked. I just found it to be kind of clunky having come from a bigger place that was doing enterprise source control management with Perforce of all things. Github as a product was fairly new back then, but everyone was trying to switch over to Git for resume reasons there. So then I go to this smaller place using git in the classic manner.
cwbriscoe 11mo ago
Wasn't that how it worked before Microsoft bought Github?
floydnoel 11mo ago
wouldn't it be cool to have an open source (maybe even p2p/federated) version of GitHub?
- lxst 11mo ago
  afaik Forgejo is working on integrating it: - https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo - https://forgefed.org/ https://forgefed.org/

seba_dos1 11mo ago

They are available as refs on the remote to pull though, they just aren't listed so don't end up mirrored either.

masklinn 11mo ago
They are listed tho. You can very much see them in info/refs.
- seba_dos1 11mo ago
  My bad! I got misled by grandparent - they are in fact mirrored with "git clone --mirror" as well.

velcrovan 11mo ago

When this kind of “sliding” happens it’s usually because the base implementation was missing functionality. Turns out CLI interfaces by themselves are (from a usability perspective) incomplete for the kind of collaboration git was designed to facilitate.

Certhas 11mo ago
In another post discussion, someone suggested git as an alternative to overleaf, a Google Docs for latex... I guess there are plenty of people with blind spots for things that are technically possible, and usabel to experts, and UI that actually empowers much broader classes of users to wield the feature.
- pastel8739 11mo ago
  If you actually use the live collaboration features of overleaf, sure, it’s not a replacement. But lots of people use overleaf to write latex by themselves. The experience is just so much worse than developing locally and tracking changes with git.
- cozzyd 11mo ago
  Is the joke that overleaf has decent git integration?
  - jdingel 11mo ago
    Overleaf doesn't support branches, etc.
    - cozzyd 11mo ago
      That's true, but at least it's possible to use via git. Great for working during a flight etc
derefr 11mo ago
> Turns out CLI interfaces by themselves are (from a usability perspective) incomplete for the kind of collaboration git was designed to facilitate. git was designed to facilitate the collaboration scheme of the Linux Kernel Mailing List, which is, as you might guess... a mailing list. Rather than a pull-request (which tries to repurpose git's branching infrastructure to support collaboration), the intended unit of in-the-large contribution / collaboration in git is supposed to be the patch. The patch contribution workflow is entirely CLI-based... if you use a CLI mail client (like Linus Torvalds did at the time git was designed.) The core "technology" of this is, on the contributor side: 1. "trailer" fields on commits (for things like `Fixes`, `Link`, `Reported-By`, etc) 2. `git format-patch`, with flags like `--cover-letter` (this is where the thing you'd think of as the "PR description" goes), `--reroll-count`, etc. 3. a codebase-specific script like Linux's `./scripts/get_maintainer.pl`, to parse out (from source-file-embedded headers) the set of people to notify explicitly about the patch — this is analogous to a PR's concept of "Assignees" + "Reviewers" 4. `git send-email`, feeding in the patch-series generated in step 2, and targeting the recipients list from step 3. (This sends out a separate email for each patch in the series, but in such a way that the messages get threaded to appear as a single conversation thread in modern email clients.) And on the maintainer side: 5. `s ~/patches/patch-foo.mbox` (i.e. a command in a CLI email client like mutt(1), in the context of the patch-series thread, to save the thread to an .mbox file) 6. `git am -3 --scissors ~/patches/patch-foo.mbox` to split the patch-series mbox file back into individual patches, convert them back into an annotated commit-series, and build that into a topic branch for testing and merging. Subsystem maintainers, meanwhile, didn't use patches to get topic branches "upstream" [= in Linus's git repo]. Linus just had the subsystem maintainers as git-remotes, and then, when nudged, fetched their integration branches, reviewed them, and merged them, with any communication about this occurring informally out-of-band. In other words, the patch flow was for low-trust collaboration, while direct fetch was for high-trust collaboration. Interestingly, in the LKML context, `git request-pull` is simply a formalization of the high-trust collaboration workflow (specifically, the out-of-band "hey, fetch my branches and review them" nudge email). It's not used for contribution, only integration; and it doesn't really do anything you can't do with an email — its only real advantages are in keeping the history of those requests within the repo itself, and for forcing requests to be specified in terms of exact git refs to prevent any confusion.

paulddraper 11mo ago

Having a web interface was really appreciated by users, it would seem.

jasode 11mo ago
>Having a web interface It's not the interface, it's the web hosting. People want a free destination server that's up 24/7 to store their repository. If it was only the web interface, people could locally install GitLab or Gitea to get a web browser UI. (Or use whatever modern IDE code editor to have a GUI instead of a CLI for git commands.) But doing that still doesn't solve what GitHub solves: a public server to host the files, issue tracking, etc. Before git & Github, people put source code for public access on SourceForge and CodeProject. The reason was the same: a zero-cost way to share code with everybody.
- udev4096 11mo ago
  GH is essentially an unlimited storage space. There are countless scripts which makes it possible to even use it as an unlimited mounted storage
  - FpUser 11mo ago
    And then one day orange gets pissed of at yet another country and it (the repo) is gone
    - wiz21c 11mo ago
      orange ?
      - deleted 11mo ago
        [deleted]
      - kevin_thibedeau 11mo ago
        The convicted felon.

udev4096 11mo ago

It still blows my mind how git has lost it's original ideas of decentralized development because of github and how github, a for-profit - centralized - close-sourced forge, became the center for lots of important open source projects. We need radicle, forgejo, gitea to catch up even more!

seunosewa 11mo ago
Once they killed mercurial on bitbucket, it was over.
afavour 11mo ago
I don’t think it’s really that surprising. git didn’t become popular because it was decentralised, it just happened to be. So it stands to reason that part doesn’t get emphasised a ton.
- int_19h 11mo ago
  It did become popular because it was decentralized, but the specific features that this enabled were less about not depending on a central server, and more about being able to work with the same repo locally with ease without having to be online for most operations (as was the case with Subversion etc). Git lets me have a complete local copy of the source with all the history, branches etc in it, so anything that doesn't require looking at the issues can be done offline if you did a sync recently. The other big point was local branches. Before DVCS, the concept of a "local branch" was generally not a thing. But now you could suddenly create a branch for each separate issue and easily switch between them while isolating unrelated changes.
lisbbb 11mo ago
I once worked at a smaller company that didn't want to shell out for github and we just hosted repos on some VM and used the ssh method. It worked. I just found it to be kind of clunky having come from a bigger place that was doing enterprise source control management with Perforce of all things. Github as a product was fairly new back then, but everyone was trying to switch over to Git for resume reasons there. So then I go to this smaller place using git in the classic manner.

cwbriscoe 11mo ago

Wasn't that how it worked before Microsoft bought Github?

floydnoel 11mo ago

wouldn't it be cool to have an open source (maybe even p2p/federated) version of GitHub?

lxst 11mo ago
afaik Forgejo is working on integrating it: - https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo - https://forgefed.org/ https://forgefed.org/