Conversation
you're silly posting if you think git actually won the VCS wars. *github* won that fight.
4
2
3

@icedquinn And git just followed.

Challenge: name different VCS
(CVS and Subversion do not count)
(I do know some, just want to see if I can learn about alternatives)

1
0
0
@kura ahem. blobcatpop darcs, pijul, monotone, rcs, bazaar, bitkeeper, mercurial, clustta, fossil
1
0
0
@icedquinn
Why do people even use forges?
And GitHub is so slow now that making a shallow clone of a medium-sized repo might be faster than trying to find something via web UI.
1
0
0

@icedquinn It’s kinda true. The real workflow intended for git (sending each other patches through email and having the actual repository decentralized) most people don’t know about.

All people know is the variant of git popularized by Github with centralized repo with a pull request interface which is what forgejo and others have copied too.

3
0
1

@icedquinn jujutsu, perforce, scss, vss (visual source safe)

1
0
0
@m0xEE social features.

there were already forges before github but you had to set them up. stuff like trac was used a lot. github just made it fit the "i can't be bothered to spend effort learning anything" mould.

its sort of nice to have issue tracking and stuff to hand but also kind of feels stagnating like now people expect to be able to shit directly in to the ticket queue (and also the ticket queues are significantly more anemic than when we used Phabricator or Roundup.)
1
0
1

@icedquinn A lot of don’t even directly use the git command line tool. They interface with it using the proprietary github cli or gui.

2
0
0
@kura blobcatthonkang does jj qualify as a vcs yet? its still kinda in the faceplate for git stage of living.
1
0
0
@SuperDicq @icedquinn i only learned about the github cli because claude wants to constantly use it lol
2
0
2
@SuperDicq well the git command line is complete ass, so.

mercurial and darcs made all the good decisions when it came to UX.
0
0
1
@SuperDicq @icedquinn
>The real workflow intended for git (sending each other patches through email and having the actual repository decentralized) most people don't know about.

That's because it sucks. First and foremost, where do you clone code from? What is the master copy? Exactly, this workflow doesn't allow for one.
0
0
2
@snacks @SuperDicq i know about the existence of forge cli tools because i see things but i've never used it.

i think they mostly get used when you're stuck suffering shit like github's UI when there's 200 open issues and your triage capacity is "marked wontfix."
0
0
1

@snacks @icedquinn Or people don’t even interact with the github cli anymore because fucking slop tools do it for them now.

2
1
3
@SuperDicq @snacks kind of surprised they didn't add an MCP endpoint as much as github loves LLMs
3
0
1

@icedquinn @snacks MCP is a meme anyway that makes everything overcomplicated. LLMs are much better at just calling cli tools directly than interacting with a special API made for them because they are trained on human writing and what humans do.

1
0
0
@SuperDicq @snacks my endless laughing forever about MCP is it finally got everyone to re-add the rexx port to software (and also document it in the process) which are two things everyone emphatically asserted simply could not be done because they just never felt like doing it.
0
0
0
@SuperDicq @snacks its just json-rpc with a handshake. the spec page makes it sound fancier than it is
0
0
1
@icedquinn
Yeah, I remember these days: you had to set up everything separately: the repo, the web front, bugzilla, something for code review, something to host release snapshots. There were SourceForge and GNU Savannah which made things a bit easier, but yeah, GH was top all-in-one and unlike SF placed greater emphasis on social features.

But aren't social features precise what took the fun out of coding? Like now instead of developing something in the dark and sharing when you felt like it, you become a full-time maintainer as if it was a commercial product. I think there was a thread a couple of months ago about how this shit only contributes to burnout marseyhmm
0
0
0
@SuperDicq @icedquinn
>The real workflow intended for git (sending each other patches through email and having the actual repository decentralized) most people don't know about.

The intended workflow also sucks ass. It only works if you have a single person managing a whole subsystem of a project where all the patches to it go against a common base for everyone for that subsystem. Once you start mixing different startpoints from a moving branch, it completely falls apart.
1
0
1
@icedquinn @SuperDicq They probably just didn't think it was worth it, it's extra infrastructure to support and maintain when they already have a CLI app and a REST API.
0
0
0

@icedquinn JJ will use git. but it does have its own VCS implementation. it works. but officially it’s only for testing.

0
0
0

@phnt @icedquinn I never said the intended workflow was good for big projects. Just saying that’s what is intended and that Github popularized a completely different workflow that is now the defacto standard even on other Git hosts that simply copy it.

0
0
0
@icedquinn
the fact that issues & prs were sort of 'bundled' with the experience is really why git ""won""
especially if you talk to most people, git = github

fossil tried integrating both at the VCS level but it failed ultimately because it was designed for sqlite and not general use.
2
0
2
@theorytoe i would argue Fossil didn't fail. it does exactly what Hipp wanted it to do, which never included being popular.

There's literally a stock "DRIVE_BY_PATCH" rejection since they basically don't care what anyone outside the monastary wants.
0
0
0

@SuperDicq @icedquinn @snacks i only interact with the gh cli when i have to gh auth login

0
0
0