Hacker News Reader

Comment by mewpmewp2 | Hacker News Reader

Why is it astonishingly?

Git is not a natural development at all. Obviously, it is a standard right now.

But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point.

I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out professionally.

Obviously now that I have over a decade of professional experience I think it's a no brainer, but I don't think it's natural to understand it as it's suggested to you. I at least kind of had to go along with it and trust that it's good. It felt frustrating at first as many other things are. Git as a thing was FAR more difficult for me to understand in my 20s than PHP and how to do anything with it was for me at teens. Coding is raw logic, Git is about imagining teamwork at scale, which is a whole other thing.

The funny thing is that I feel like I was overall still more productive when I was at my teens building stuff solo with FileZilla and PHP, compared to a corporate environment now with all the processes and 1000s of engineers.

View on HN

> Why is it astonishingly?

Git is still a baby as these things go. Software version control systems go back to the early 1960s and descended from manual processes used to manage documents in large organizations, blueprints, and such from the early 20th century. Don’t imagine the Manhattan Project functioned by just passing around bundles of paper! There were staffs of people whose job was to manage document control! And I don’t mean “control” in the sense of secrecy, but making sure everybody was on the the same revision at the same time.

And for a field so steeped in building its own tools and automating human effort in development it is indeed astonishing revision control took so long to be accepted.

> Git is not a natural development at all. Obviously, it is a standard right now.

Most standard tools we use today are not obvious to beginners nor would they be the first thing that beginners reach for.

But senior developers can understand the problems that they claim to address, and why they are important and common problems.

You wouldn't believe the amount of crap I take whenever I introduce very basic version control at the various 3 to 6 man shops I find work at these days.

I'm 100% sure that once I left that the devs went back to remote server crash and burn FTP development...they couldn't be bothered with the "hassle" and unneeded headaches of git.

> I'm 100% sure that once I left that the devs went back to remote server crash and burn FTP development...they couldn't be bothered with the "hassle" and unneeded headaches of git.

Have you considered introducing Mercurial or even Subversion?

While Git may be a kind of an industry 'standard', if you're starting from zero, some of its concepts may be a bit mind-bending for folks, and it has often been commented that Hg seems to have a more beginner-friendly interface.

And if branching isn't going to be used (a large strength of git/hg), then Subversion may have an even simpler mental model (svn of course does branching, but the others are more optimized for it).

If folks are doing FTP-push deployment, then moving to 'just' SVN-push (commit) deployment can be an improvement.

There was a new hire who was told to make a small change in a piece of server software, found the repo, read the docs, made the change, ran it in testing, and pushed to prod. Cue the 'senior engineer' screaming bloody blue murder because he'd been directly monkeypatching the servers for 3 years with no vc and no backups.

That’s… not a senior engineer. Whatever his title may have been.

This could have been written and 2014 and 2004 (hi, it's me). There will always be people who don't use it and others who won't remember a time when they hadn't used it :P

Add 1984 to that list of dates. We used PVCS on MSDOS

By 1994 I had moved to other companies and a NeXT equivalent to svn with a good GUI - and then ClearCase.

Hello, fellow old person. I was just remembering PVCS (Polytron Version Control System) since it was the first I worked with back in the 80s. Now I see that it's still out there, with the latest release in 2021. Which is insane.

>But senior developers can understand the problems that they claim to address, and why they are important and common problems.

Senior developers have simply grown accustomed to the warts, and accepted their fate - some even celebrating their mastery of the warts as necessary knowledge.

The only pragmatic reason not to change things is the compatibility chaos that will ensue and the resources required - not that problems don't exist.

> some even celebrating their mastery of the warts as necessary knowledge.

Hi git fans!

I don’t know if I agree that it’s unnatural.

It only takes doing index73.php and index_old3.php for a few months and then eventually screwing up (unless you’re perfect) to realize how dumb putting numbers and _old4 at the end of names is. Then at that point, you naturally go look if there’s a better way.

> Then at that point, you naturally go look if there’s a better way.

That might be true now but it wasn’t always. Plenty of shops didn’t have any version control at all. And the build was whatever came off your local dev box. And “local dev box” wasn’t even a term…

Yes, so you invent CVS, not git.

You invent VMS versioned files, and RCS. :)

BTW file versioning in the filesystem predated the development of VMS by about 15 years, RCS by about 20.

(indirect reference ITS and TENEX ... :-))

>Git is not a natural development at all.

It's a false dichotomy. Before git there were other version managements systems which would've fit your use case much better than git. Subversion is the easiest perhaps.

Git is pretty unnatural, but CVS? That is much closer to the "copy a shared file back and forth between people", except with nice things such as "keep track of who is editing what", "know what the latest edition is", and "keep track of the history".

That said, if I was going to start out teaching someone coding today, version control would be timestamped .zip files.

Ouch, please don't. Anything else like bzr or hg or svn will be easier to grasp than git, can work locally too (IIRC for Subversion) and not much harder than zip files — don't get them used to the wrong mental model and bad habits.

>That said, if I was going to start out teaching someone coding today, version control would be timestamped .zip files.

Oh no, we're in a different time zone.

>We'll put the timezone in.

Oh no, it's daylight savings time.

To be fair that's easy, just always use UTC for everyone. Or just the unix timestamp in seconds or millis if you want to be safer.

Entirely besides the point I was trying to make. I wasn’t trying to say that it’s a good idea for a team, but that git is complicated. Too complicated for beginners.

But someone works in Arizona!

Well yeah for hobby use you're right that it is "normal" that it took a long time to get there. But professional use is completely different. That's the part they are referring to I'd say.

> Git is not a natural development at all. Obviously, it is a standard right now.

Git is actually an unnatural development. Its UI is atrocious. And it worked like crap on Windows for forever.

Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got out of their way and was generally fine.

Then Github won due to VC cash dumping and foisted Git on all of us. Source control was no longer fine.

Thankfully, there is now Jujutsu(jj) which works on top of the Git storage layer so you can forget about the craptastic UI of Git. Source control is now fine again.

GitHub won because it was good.

SourceForge had a messy interface and frankly I hated it. Google Code was like frozen in time, like most Google projects. Microsoft’s thing — I don’t even remember the name — felt half assed and like they were going to abandon it… and they abandoned it. There were also others… none of which I even think were serious enough.

Also Git won because SVN and CVS were centralized VCSes and you needed a server. I can just make Git repos before I even know if a project is serious.

There were other distributed VCSes of course, like Hg, but they either cost $ or wasn’t backed by a major user… like Linux. I admittedly just waited this one out and chose Git because it was more popular.

You either meant Visual SourceSafe or Team Foundation Server for the Microsoft product.

SourceSafe did get abandoned... because your source wasn't actually safe in it.

Its replacement, Team Foundation Server got rebranded as Azure DevOps; but the product's still around, 19 years later.

Yes, but it's source control shifted to git years ago (I think you can still use TFS, but it's strongly legacy ) and git is mich better than TFS ever was.

True on both counts. (They’re never going to be able to kill TFVC entirely, but it’s disabled for new projects by default, and they’re going to take away the switch to reenable it.)

This discussion was about git, not GitHub. There's a difference.

If git doesn't need a server, then why do you need Github?

GitHub won because it was free.

GitHub won because they built a great product. It was better than all the alternatives and people flocked to it for that reason.

Git itself is mediocre, and some other DVCS like Mercurial could have won out, although HgHub really doesn't have the same ring to it. The halo effect from the Linux kernel was also a factor. But the VC cash dump and Microsoft buyout came later, people used GitHub because it was better than the rest.

Mercurial lost because it had the wrong mindshare. It was the Betamax of version control and while it had a lot of positives, it never gained the critical mass to overcome VHS.

Which is such a tragedy. Hg is such a simple pleasure to work with.

It's sad that this discussion about git being the standard turned into "Why GitHub won" -- shows that people conflate the two. Who said GitHub had anything to do with git becoming the standard in the first place? (I only even heard of GitHub long after we'd adopted git at a previous workplace.)

git didn't win because of GitHub. Sure, GitHub helped a lot. But actually, it's because its a DVCS, and it does branching and merging way better than anything I've seen so far.

You can thank BitKeeper for all of this, and Andrew Tridgwell for forcing Linus Torvalds into creating git.

You don’t think if the company behind GitHub went all-in on mercurial that might have emerged as the winner? There were plenty of companies using either. Git wasn’t the only distributed game in town. I definitely think GitHub had a lot to do with it.

Before there was GitHub there was Sourceforge. Sourceforge supported several different protocols and git still won.

Gits internals can be confusing at first, but once you understand them there's really nothing you can't do. Being distributed by design also helps.

Sourceforge had a flat namespace for projects and required you to manually apply for each project. It was a PITA and that added a huge barrier to entry.

Plus it didn’t have a mechanism to send contributions. I think GitHub “won” because of its web-based PR system.

Sourceforge was complete garbage though. I hated, hated when projects were hosted on it. It was slow, full of ads, impossible to find what you need to download..

GitHub is to sourceforge what Facebook was to MySpace. MySpace was first but it was buggy as hell.

You're kind of disproving the point you're trying to make, IMO: Saying "GitHub made git the standard!" is kind of like saying "Facebook invented social media!"

Nope, MySpace did. Or blogs, for that matter. Facebook just co-opted the phenomenon, and has for many become synonymous with it. Just like GitHub has managed to do with git.

SF started to be filled with ads only in a second phase. By memory I would say around 2010, and checking Wikipedia it says it changes ownership in 2012. But when it was the de facto "central repository" for Linux softwares codebases, I don't remember it being full of ads.

That comparison is pretty harsh and really underemphasizes how awful sourceforge was. Myspace was mostly fine, death by feature creep. Sourceforge was a flaming pile of garbage that was poorly designed, ad laden, AND silently bundled in ad/spyware to normal downloads.

A more apt comparison would be comparing Facebook to a hypothetical social media site that when you click on a thumbnail of a user's image, you get a fullsize image of something like goatse...which thankfully doesn't exist(yet).

You mean the comparison is too mild? https://www.merriam-webster.com/dictionary/harsh

I read it as harsh to MySpace, because that was very unfair to MySpace imo

Oh, meant harsh to Myspace, which wasn't that bad really.

Sourceforge wasn't the only offering at the time.

Lots of companies were doing Git and Mercurial "forges" at the time. Many of them were better than Github.

Everything was evolving nicely (including Git and Github) until Github used VC money to offer everything for free to blow everybody out in order to lock people into their product (for example--export of anything other than code is still hit or miss on Github).

At which point, everything in the source control space completely collapsed.

That's such a weird rewriting of history. I know blaming VC is very fun and all, but Bitbucket, originally centered around mercurial, had just as much resources as GitHub and even more. Tons of early contributors to git and the ecosystem were from google and Microsoft. Microsoft started using and shifting towards gif when GitHub was still a baby, etc.

> That's such a weird rewriting of history. I know blaming VC is very fun and all, but Bitbucket, originally centered around mercurial, had just as much resources as GitHub and even more.

You might want to go review your history before accusing someone else of that.

Github took $100 million from VCs in 2012. It then took another $250 million from VCs in 2015. Who the hell else was even within an order of magnitude of that in the same timeframe? Nobody. (Gitlab took almost the same amounts but did so somewhere between 5-8 years later depending upon how you count).

Bitbucket got bought by Atlassian in 2012. Atlassian was bootstrapped until it took $60 million in VC in 2010 and had revenues (not profits) of about $100 million in that time frame. It had nowhere near the resources to be able to drop the equivalent of $350 million on Bitbucket between 2012-2015.

Minor nit.

> Bitbucket got bought by Atlassian in 2012.

29th September 2010[0] (just over a month after Atlassian raised the $60M.) ~18 months before Github took any VC money. If the VC money was key to Github's success, why did Atlassian/Bitbucket's 18 month head start not get them anywhere?

[0] https://web.archive.org/web/20160303204710/http://www.itwire...

By 2012 the writing was already on the wall. This was already well into the first PaaS era with Heroku, Engine Yard, etc. Github was bootstrapped, and using git was a grassroots movement. It was just better than what most people had been using. I never looked back after first switching from SVN to git in 2009.

VCs didn't make git successful, developers did.

Sure, but 2010 to 2012 might as well be two different eras in the context of VCS adoption. Things changed very quickly.

In any case,that doesn't really matter considering that git had big players adopting before GitHub got any sizeable investment. And I'm not just talking about Linux. Rails migrated towards it when GitHub was still in beta.

Sourceforge isn't GitHub. What's the relevance?

If you think SF+CVS is equivalent to GitHub+Git then you never used SF+CVS. Git won because of GitHub, specifically, not because generically it could be hosted on the Internet.

No, GitHub won because of git, lots of VC (later MS) money, and brilliant marketing that makes people think "Git won because of GitHub".

To be fair, by the time git came around, sourceforge had been enshitifying itself for 10 years or so. Git would be popular without github, github just makes things easier.

> Git would be popular without github,

Yep.

> github just makes things easier.

Which is the transition between steps 1 and 2 of Embrace, Extend, Extinguish. Though the last step is nowadays perhaps unnecessary, depending on how you look at it: Having co-opted FOSS software like git, what you need to extinguish is not that itself, just any other way to use it than your own. The main example of step 2 was of course "Pull Requests".

yeah, git is just the right layer of indirection to support everyone's weird take on how the workflow should go, so you can just use it however you want.

> I definitely think GitHub had a lot to do with it.

And I definitely think you're wrong. GitHub has managed to get itself conflated with git, and has benefitting hugely from this confusion.

Yes, git has solved a big problem with version control: it has made transactional atomic changesets (commits in the git parlance) mainstream. A git repository is a tree of atomic changesets that group changes into meaningful chunks as opposed to a versioned tree of files where changes to each file are harder to trace back to the intent, i.e. whether or not they are related.

Atomic commits can also easily be moved around (since the repository is a tree of commits with the commits being leaves), and they also make merging simpler in many scenarios.

Larry McVoy was famously wont to engage in trolling upon the Linux Kernel Mailing List, whereupon he did boast of his BitKeeper, which possessed atomic changesets. Concurrently, he did deride Subversion for its lack of the same. Thus, a great drama did ensue, one which ultimately bestowed upon us the creation of git.

git has also succeeded as a DVCS where others have faltered, for various reasons. For there have been monotone, darcs and other such systems; yet, it is chiefly git that has endured.

> Larry McVoy was famously wont to engage in trolling upon the Linux Kernel Mailing List, whereupon he did boast of his BitKeeper, which possessed atomic changesets. Concurrently, he did deride Subversion for its lack of the same

Subversion definitely has atomic commits. That was it's major advance over CVS.

The major difference between svn and git/hg is svn assumes a centralised repository, whereas git/hg are designed to work as distributed repositories that exchange change sets.

Turns out that you can build sophisticated work flows on top of features they added to support that distributed model - things like PR's. These things are useful even if you have a single centralised monorepositiry of the style svn insists on.

But atomic commits aren't part distributed feature set. You need them in a monorepositiry. After you've experienced your CVS repository being turned into a mess by two people doing a commit at the same time that becomes obvious.

> it has made transactional atomic changesets (commits in the git parlance) mainstream

Nope. Subversion made them mainstream:

"An svn commit operation publishes changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents; create, delete, rename, and copy files and directories; and then commit a complete set of changes as an atomic transaction.

By atomic transaction, we mean simply this: either all of the changes happen in the repository, or none of them happens. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions." [0]

[0] https://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html

git isn't foisted on anyone, although I will acknowledge that if you're working anywhere remotely web-y, you'll be required to use it.

But the vast majority of people I personally see who complain about git simply don't know how to use it, and apparently don't care to learn. They say it's hard, and then they joke about never learning more than three git commands. Can't we do better? Is that where the bar is?

It's not that the basics of git are hard. It's that there are 30 footguns you're forced to deal with every time you want to do anything, just because someone somewhere once had to use one of them -- probably caused by another one of them.

Git lovers mostly use it as a file copy service.

> Git[‘s] UI is atrocious.

Well, that’s in the eye of the beholder. Yes, I hate the ‘program command’ syntax (“git add”, “git commit” etc) but I just call git-add etc and for me those commands are pretty clear.

But I understand how git works. I imagine most people treat it as a black box and then its behavior probably is rather obscure. I don’t think it was intended for that use case.

> Well, that’s in the eye of the beholder.

I acknowledge that Git is really good on a technical level, but don't like the CLI experience regardless.

Instead, I much prefer to use tools like GitKraken (paid), SourceTree (free, limited platform support), Git Cola (free, lightweight, a bit basic) and know that most of my colleagues just use the Git integration in their IDE of choice.

Working that way, it's a decidedly pleasant experience, not unlike using visual merge tools like Meld, where you can also stage individual lines/code blocks and operate with branches and tags in a very visual and obvious manner.

That said, sometimes the support for Git LFS and things like submodules is all over the place and I've had cases where not adding node_modules or something like that to .gitignore has made the UI unresponsive with how much stuff initially shows up in the working copy, so sometimes you still have to drop down to the CLI and do a fix herer and there.

git has plenty I like and lots of things I would rather not do, but I find most GUIs too obfuscating. I do patch adds, I prefer resolving conflicts in the raw file, and as many plugins as I’ve tried for vim to make git “pretty”, they just don’t hit for me. I used Kraken for a while but ultimately it just felt like unnecessary fluff - knowing the commands I’m using makes me feel like I know what’s going to happen, and GUIs make me feel like I’m not sure. I’m happy for my coworkers that use them, and I’m also usually the first person to get a ping when something beyond what makes sense in the GUI comes up.

I'm consistently baffled by the people who don't understand how git works who then complain that it's hard. Yes, of course something you don't know is hard. Version control is a hard problem; I'm not sure why so many expect it to be unicorns and rainbows.

>> Git[‘s] UI is atrocious. […] Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial.

> Well, that’s in the eye of the beholder. […]

I would say it is not.

Usability testing is a thing, and products can get better and worse scores when trying to do the same task / reach the same result. I'm not aware of any published studies on the topic, but I would not be surprised if Git got lower scores than Hg on UI/UX, even though they can basically do the same thing (distributed development).

Given the GP trained people on multiple version control systems, including another distributed one (hg), and people mostly had a problem with Git, I would say Git is the problem.

I am unable to do anything with Photoshop beyond starting it and exiting. I have no idea how or even what it does beyond somehow modifying photos. That’s not photoshop’s problem, it’s that I don’t know what I’m doing. So I just don’t use it.

I only hear git complaints from people who don’t have an internal model that reflects what git is doing (I’ll agree that it uses a couple — but only a couple — of terms in a way that might violate some people’s intuitive model). But if you know what you want to accomplish the command line is pretty unremarkable.

But when you don’t know how the tool works you easily get snarled. And when you blindly resort to various “cheat sheet” sites it’s a crap shoot whether you “fix” your problem (how would you know?) or make things worse. That’s like me with photoshop.

I used to see this with CVS too

> I am unable to do anything with Photoshop beyond starting it and exiting. I have no idea how or even what it does beyond somehow modifying photos. That’s not photoshop’s problem, it’s that I don’t know what I’m doing. So I just don’t use it.

As stated up-thread:

> Over time, I taught non-computer people who used Windows all of CVS, Subversion, and Mercurial. They got each one and why things were better. The first time they had to recover something, they really got it. Source control got out of their way and was generally fine.

Seems that things only got hard(er) teaching people with Git.

> I only hear git complaints from people who don’t have an internal model that reflects what git is doing

Yeah, every time someone says that:

> git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.

* Isaac Wolkerstorfer, https://twitter.com/agnoster/status/44636629423497217

In the past I have used RCS, CVS, and Subversion. I never had to learn any kind of internal model for any of them.

Reply on news.ycombinator.com