Hacker News Reader

Comment by Tomis02 | Hacker News Reader

It's been about a decade since git "won" the version control war due to the (yet another) unjustified tech hype wave, and we're still having difficulties with what should be trivial tasks. I remember reading a comment by Linus Torvalds being surprised that people started using git directly rather than putting a friendlier layer on top. If it was capable of introspection, the industry would admit it made a mistake by going with git and switch to another VCS instead, rather than wasting huge amounts of time on a tool whose only job is to save text.

View on HN

> whose only job is to save text

I don't see git as a tool to save text, its for coordinating changes on the same 'text' by multiple people, and doing so quite precisely and reliably, without blocking anyone's path forward. Try that with word.

It could be better, yes. But I'm always surprised by the hate git gets. Its an amazing tool and miles ahead of the tools we created for non-developers (word, google docs, etc).

Maybe its because I'm old enough to remember when subversion was king.

This. Git is miles ahead of anything else.

Is is entirely intuitive to everyone? No.

Did developers always have trouble with version control and merging? Yes.

In my experience most devs don't grok version control, period. It does not matter if it's SVN, CVS, RCS, Visual Source Safe, Clearcase, Perforce, you name it. Or now git.

If you think Git is miles ahead of anything else, you probably haven't really used anything else.

I don't think that Git sucks, it's usable. But there are better alternatives.

Do tell. Your post is missing examples of better alternatives and why they are better.

FWIW, yes I have used others, maybe not the ones you have. I have used some of the ones mentioned in my list of examples, though not all but also others not mentioned.

Alternatives like: fossil[1], mercurial[2], pijul[3], veracity[4].

[1] https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...

[2] https://www.mercurial-scm.org/

[3] https://stackoverflow.blog/2023/05/23/for-those-who-just-don...

[4] http://veracity-scm.com/

I've only used one of those.

Mercurial: I was not impressed. Yes it sort of works but if you know git, you just miss the fact that everything (tags and branches) in git is just a label. At least that's what I missed in the two years I had to use mercurial.

Fossil: Haven't used it but the main advantages touted in the doc you linked to aren't advantages to me. I.e. the only thing I'd want from it are the actual file versioning parts. And then I read things like

    You can say "fossil all sync" on a laptop prior to taking it off the network hosting those repos, as before going on a trip. It doesn't matter if those repos are private and restricted to your company network or public Internet-hosted repos, you get synced up with everything you need while off-network.

Err, yeah, I `git pull` my repo(s) before going on a trip and it doesn't matter if they're private and restricted to my company network and I am synced up with everything I need while off-network. So?

Pijul: Sounds interesting from a first read but I'd take some time to actually read about it and try it out for real.

Yes, `git pull` and you have your repo synced. But guess why people are using Github (or alternative forges)? They want issues and maybe documentation/wiki etc. And Fossil has all those features too and that's the "all" you sync. ;)

That is fair enough if that is what you want.

Personally I subscribe more to the UNIX philosophy here, where I want my tool to solve one thing but be great at being combined with other tools in ways that the original authors probably never imagined.

E.g. I've used `git` in many scenarios.

I've used it with just one other developer where we'd push and pull from each other's laptops via ssh and no central server whatsoever. In that same place we used git for doing backups. We used Bugzilla for bugtracking with that.

I've used `git` w/ `git svn` for about two years in a company that used SVN and nobody knew I was even using and reaping the benefits of `git`, while they were having loads of issues with branching, tagging and conflicts. I showed some people. They wouldn't listen. IIRC we used Rational Clearquest or something like that in that place. It's been a while and it wasn't fun at all.

I've used `git` w/ a central server via SSH. No, not github w/ ssh protocol, just our own central server. Special user whose "login shell" was `git receiving data`. This is the Bugzilla place actually!

I've used `git` w/ a central server via HTTP. Funnily enough this was also the same place as with SSH but ya know, can't expose SSH externally, right? So HTTP it was via an Apache Proxy. Yes that long ago. So yeah Bugzilla place again. But also used this setup at other places that used Jira. Jira 3 mind you. Did we use GreenHopper there? I'm not sure any more. It's been a loooong time.

I've used `git` with bitbucket as the central server. Definitely with GreenHopper in Jira!

I've used `git` with `github` as the central server. Jira Cloud. GreenHopper has now for a long time been "Jira Agile" or "Jira Software" or whatever the nom du jour might be since they bought it.

Do you see the one constant in here? `git`! Because it does one thing and it does one thing well and you can combine it with all these other tools and environments and integrate with them. You don't have to convince anyone that "My tool's integrated issue tracking is the best, throw away your 20 years in tool X and migrate everyone and everything over". You "just" need to convince them, that of course `git` is better than Clearcase, which is uphill battle enough for one year.

Nevermind the wikis in use in those places. Don't even remember which where necessarily. All the way from the none, through Wikimedia, MoinMoin, Confluence and Jive (Jive leaves a particularly bad taste as it was in the Clearcase place and used as a company internal social media platform everyone was supposed to use for 'everything' :shudder:)

I've worked with Fossil for two years and half, and same things apply.

- I've used Fossil within a team of three and we were able to sync from each other's laptop without central server. We used it also for bug tracking, with no additional stuff to install.

- I've used in the same company with larger teams on different projects on central server over https or ssh.

- We've worked with github and other external central servers of Git repositories.

There's also one constant here: `fossil` :) It's a nice discovery for me, after Mercury (which I still use for my personal projects) and they are doing the job with ease (clean and less error prone interfaces.) I'm not selling you something and not trying to convince you they're better (I don't care as I can use them and interact with your git repos and will be transparent) ; alternatives were asked and i point some out, that's all. :)

If you want something you can use with existing git repos, there's also https://github.com/martinvonz/jj and https://sapling-scm.com/

Oh, I forgot about Jujutsu ^^ It's on my to-test list 'cause it promise best of both worlds (I'm a mercurial regular user.)

Also to use with existing git repos: https://gitless.com/ and https://github.com/frostming/legit

> whose only job is to save text

It's a hyperbole, a figure of speech used to make a point. I'm pretty sure everyone on HN knows what git is used for.

> Maybe its because I'm old enough to remember when subversion was king.

I used SVN for more than a year. Why would you compare git with SVN rather than other DVCS like Mercurial?

> It's a hyperbole, a figure of speech used to make a point. I'm pretty sure everyone on HN knows what git is used for.

I know. The hyperbole makes it sound as if gits job is actually quite simple and we could easily have a better system. But I disagree with that, I don't believe it is simple. Most other tools have and are failing still at this.

> Why would you compare it with SVN rather than other DVCS like Mercurial?

Because SVN ruled the world back then and that is what I and many other devs used. Many of us went from SVN to Git without even knowing what Mercurial was. That explains why I was (eventually) so in awe of git, had I gone from Mercurial to Git I might have lamented the loss of a more friendly system. I do actually remember doing the odd thing with mercurial and it being much smoother to work with, but then git was already becoming the dominant player.

> Many of us went from SVN to Git without even knowing what Mercurial was.

Yeah I know, that's the problem. In other words, many of us decided git is the best because many of us didn't know any better.

But it's been more than a decade, surely that's enough time to reevaluate one's position.

But, be honest, git was better than mercurial as well.

And the reason that it's better is that the support is universal (now). Even back when the battle was being actively waged between git and hg, the popularity of git made it a better choice for pretty much everyone.

> Maybe its because I'm old enough to remember when subversion was king.

Heh. I'm old enough to remember when CVS was king. Subversion was a huge improvement. Git was too. I have every reason to believe further huge improvements are possible. They might have to be gargantuan though to overcome inertia by now.

Just look at what sucks in Git.

Large file handling and submodule/subtree.

submodule and subtree are difficult concepts that look easy at a first glance. That is not the fault of the implementation.

For record that's something SVN had. It's difficult in distributed setting.

And CVS was a huge step up from RCS and SCCS synced via sneakernet, well, it seemed huge at the time, now it seems like a tiny step compared to everything that came after.

Hard agree.

Weekly, I witness co-workers confused about git, I see posts online asking for help, I see articles like the one here once again trying in vain to explain something that should be simple.

In all my time coding, I don't remember anyone wasting hours trying to undo some mess they'd made in SVN, TFVC, Perforce, etc.

Tools exist to make our lives easier. If they can't do that, they don't deserve our time.

It is a true power tool. It does need an initial investment to get over the hump but I would never go back to SVN.

It doesn't take a huge amount of time to really learn the basic concepts and then maybe the 10 most used commands (I suggest using git cat-file -p to navigate a repo and history manually). There is a wealth of functionality and an inconsistent terminology, but you can quickly look that up when you actually need it.

I feel like some people are better at the context switch between the project they are working on and git. I am not good at that context switch.

I remember seeing people blow up their SVN projects fairly often, usually from trying to move folders around without telling it. Though I don't remember those turning into three developers hovering over one computer the way that git errors so often do.

Confusion over svn was standard operating procedure over here for years before teams started using git regularly. I think I'm still the only one here that really understands how svn merge and svnmerge.py work, and have had to detangle plenty of messes over the years.

We'd kind of standardized on trunk-based development because everyone was afraid of even attempting merges.

But git has a very slightly improved merge algorithm than svn (so they say) — but merge conflicts were less painful and less likely to happen on svn.

The only real advantage git has is bandwidth and disk space —- not that it uses bandwidth and disk space more efficiently —- only that we all have more of both, so it seems more useful than subversion (or whatever else you were using before) when you had limited disk space so you didn’t pass around infinite copies of everything.

The worst thing is that GIT makes some people NOT do version management. To avoid dealing with GIT, they’ll go https://xkcd.com/1597/ and so suddenly major rewrites of code are suddenly one “pull - stage - commit - push - PR” affecting 100’s of files…

In 2013, it was far from clear that git would win. There was still a sizable amount of users of darcs, Mercurial, svn, and even cvs. Many of the tools of that era would have plugins to support all of them.

I wish we still had that, because git monoculture also means that anything that replaces git first has to reimplement git. This means that just like ASCII or scroll lock buttons, we're stuck with git mostly forever.

> unjustified tech hype wave

git won for good reasons, it's clearly better than what came before it. It may be popular to shit on it now (similarly for jquery), but when it arrived on the scene it was clearly an improvement.

It won because it was used by Linux kernel first and second because gave it an interface to ease things. https://stackoverflow.blog/2023/01/09/beyond-git-the-other-v...

Plus the gorilla that is GitHub. Which was significantly better than the contemporary alternatives of SourceForge, BitBucket, or Google Code.

In a parallel universe, had there been a HgHub (with same strong initial iteration as GitHub), I have no doubt that mercurial would have won.

The way I got into git was: I was working on a project using Subversion and wanted to be able to work on train rides (and internet connectivity on trains wasn't a thing back in 2007). Initially I tried SVK, but I found that git-svn actually worked better.

In fact, it worked so well, I stopped using "svn merge" (which took 5+ minutes on our repository for every merge), and started using "git merge" with git-svn instead (which reduced the merge time to <3s, and even the extra git<->svn sync overhead cost only 30s or so). As a bonus, git also reported fewer "merge conflicts" (svn at the time had issues repeatedly merging from a branch to trunk).

So when I ended up picking a DVCS for another project, git was the natural choice since I already knew it. I imagine there are a lot of developers who started out on SVN and took a similar route to learning git, so having a high-quality Subversion bridge turned out to be one of the critical features on the road to adoption. This advantage in adoption then snowballed via forges like GitHub.

(there was a name missing:) and second because Github gave it an interface

This talk by Linus is iconic, if you haven't watched it you should.

https://www.youtube.com/watch?v=4XpnKHJAok8

He talks about what SVN got wrong, specifically, that it made branching easy and it's the merging that's the important piece. Git won because it made merging easy.

I don’t think that git is better than its predecessors. Why do you think it’s better?

Because I've been in this industry long enough to have used the tech that came before.

> git won for good reasons, it's clearly better than what came before it.

You guys keep covering your eyes and ears, pretending that Git and SVN were the only players on the VCS market. That was not the case.

Sure, SVN had problems and people wanted something better, but Git was far from the being the best alternative for the average software development team.

> It may be popular to shit on it now

I was shitting on it 10 years ago, along with a small minority, and for good reason. Unfortunately, the hype was too strong, and we are where we are.

>It's been about a decade since git "won" the version control war due to the (yet another) unjustified tech hype wave

Hah, I've recently wrote a post about similar issue - why we may be locked with git.

>So what's the issue here? I'm worried that just because GitHub is so good, then unless they decouple from git as letters management engine and allow any/other, then we will be locked with git.

https://trolololo.xyz/github

https://news.ycombinator.com/item?id=38098109

Git won because it's better than Subversion, and because of GitHub.

I think the parent comment is trying to say that not all project requires feature rich tool like Git. I also suspect for many many project subversion is good enough.

How is git better than svn?

You don't need to lock tree to deal with merges, you can edit your own commits (e.g. scrub someone due to GDPR from history), works offline, relatively fast.

The trade off is complexity. Subversion was very easy to use. You could work around it’s limitations, if your project wasn’t the Linux kernel.

Just being able to create a local branch, experiment with some changes and then either scrap the whole thing or merge them back is a big productivity boost. I feel like with SVN making a branch was like a "big deal" and something you had to think about, whereas in git making a branch is cheap and just part of a normal work flow.

Making an svn branch is not a big deal and you can certainly create a branch in svn and scrap it. It seems that the git hype of 10 or so years ago was very effective.

It's true that it's been a decade since I used SVN so I could be misremebering, I just remember branching and merging being a much larger pain than in git.

I know what you mean, when git was gaining popularity I do remember people saying that branching being better/easier in git. I do think it was overstated back then and just not true. I haven’t used svn in years as well, but I think it was mostly due to the hype than any objective merit.

Branches were made by copying the directory tree, and svn doesn't have local commits so it always went straight to the server.

I think svn also originally didn't have merging, or at the very least it was such a bad experience svnmerge.py was created and really common to use. Even once it got good it was mostly the equivalent of using git cherry-pick to pull commits across branches, though it did get a special "reintegrate" mode for diffing a branch and applying that back to trunk (and I remember there being something about it being possible to accidentally undo commits if you weren't fully up to date when running it...?)

Edit: I remember now, all changes on trunk had to be merged into your branch first, or reintegrate would interpret it as if your branch undid those commits and remove the changes from trunk. It basically made trunk look exactly the same as the branch did at that moment.

Making an svn branch and scrapping it, indeed never was a big deal.

Making an svn branch and merging it, now that was a huge issue. "svn merge" sucked compared to "git merge".

For the project I was managing back in 2007 I started using git-svn, because importing Subversion commits into git, using "git merge", and then exporting commits back to the subversion server, was faster and worked better than "svn merge" did (back in 2007).

Reply on news.ycombinator.com