The points I made are just as relevant to "cheaper". costs/benefits need to be compared against population usage. You are not arguing against the data I gave.
If you build cycling infrastructure, you get more cyclists. 'Build it and they will come' turned out to be true in the examples I gave (and there are many other examples out there).
The question is if you want increase that 3%. For me it's a no-brainer, given the benefits.
That's amazing. Meanwhile, in some other first world countries (allegedly): "come on bro, just one more lane, and increase the speed limit, that'll definitely fix traffic and make everything better".
Yes, it really does. Traffic engineering is an entire field of civil engineering. This has been studied for over a century, and the effect of widening highways and increasing speed limits can be simulated mathematically:
It's the psychology that they don't take into account. Making travel times better in one area makes more people take more trips or change when they take trips, making it worse again until some kind of equilibrium is reached over a year or a couple of years (which is often around the same kind of travel times you had before the upgrade).
You could absolutely make traffic better by increasing lanes somewhere where the population was generally decreasing at a decent rate, of course, but population growth is another source in many places - you can't build enough new capacity in a lot of areas to keep up with the growth.
The fundamental problem is that cars are a very space inefficient way of moving people - that's why we see this problem in cities but don't tend to see it in rural areas (because they don't have many people but have plenty of space, so the volumetric inefficiency doesn't matter), and why you don't tend to see the issue much with rail other transit - since they have so much passenger capacity for the space they take up, if there's induced demand there's often scope for increasing service frequency.
Out of curiosity why wouldn't it be? Technology is improving all the time. We'll solve CO2 in the atmosphere and at the point every person on earth will want a green car.
> There is little dispute among transportation researchers that expanding highway capacity increases vehicle use. This phenomenon is commonly known as induced demand, and it demonstrates a fundamental economic principle: individuals tend to consume more of a good as the price of the good falls. In other words, wider highways increase traffic speeds and reduce the time cost of driving, thereby inducing additional vehicle travel. In the short run, when residential and employment locations are fixed, faster peak period highway speeds attract drivers from alternate routes, modes, and times of day. Then, in the long-run, faster speeds encourage additional social and economic behavior in areas made more accessible by the new highway capacity, which further increases traffic volumes.
> Research studies since the 1960s have suggested that, because of induced demand, the hoped-for benefits from highway expansion tend to be short-lived and do not provide lasting relief to traffic congestion. Early studies by Downs (1962), Smeed (1968), and Thomson (1977) go so far as to argue that, over time and without any other offsetting deterrent, rush-hour traffic speeds tend to revert to their pre-expansion levels. The finding has even been dubbed the Fundamental Law of Road Congestion (Downs, 1962), which asserts that the elasticity of vehicle miles traveled with respect to lane mileage is equal to one, implying that driving increases in exact proportion to highway capacity additions.
In Sydney it is one more tunnel! I am not against it as the infra could
be used by an army of electric buses that could be a psuedo-metro. Please do that!
Seriously, at least in France the big success story in my book has been the use of heavy-duty buses to expand transit networks. You just gotta take over existing lanes, and you make your main bus lanes have buses every 5 minutes or so. It's not ideal but it exists and works.
Highly recommend as an alternative to wishing for metro lines.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
Veracity: `(C) 2010-2014 SourceGear`. I don't want to be that guy, but: really?
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. ;)
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. :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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).
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.
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.
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.
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.
> Traffic fatalities would fall nearly to 0 if we made all speed limits 25mph.
You're saying it as if it's a bad thing. Nah, it would be great (with some exceptions that can be addressed). It would encourage ubiquitous and efficient public transport.
Consider moving to Switzerland then. Not only they're discussing an universal 30km/h (18mph) limit in urban areas, but some cities are also tweaking traffic lights to maximise stopped time on top of that.
I live in a 30kmph zone in Switzerland and it works fine. I'm not sure what the problem is.
It's a really common speed limit in Europe/UK and is suitable for residential city streets. On Geoguesser I have seen similar US streets that are 40mph which looks completely unsafe.
Switzerland has 1/2 the population of New Jersey. Are the accomplishments in public transportation because the Swiss have solved some fundamental issues that no one else possibility could, a truly amazing feat that the world should look to? Or do certain things work better under certain conditions, and it's pretty much the exact same thing everyone does that doesn't scale?
> Are the accomplishments in public transportation because the Swiss have solved some fundamental issues that no one else possibility could, a truly amazing feat that the world should look to?
Loads of other countries also have great public transportation, especially when the current state of the USA is what’s being compared against. Possibly including the USA itself before cars got going.
> Or do certain things work better under certain conditions, and it's pretty much the exact same thing everything that probably doesn't scale?
The thing which public transport needs to be good at scaling is passengers per hour per land area.
In this regard, approximately all public transport — bus, light rail, heavy rail, tram, ferry, underground — scales better than cars.
This is why the Swiss built them, as all those steep hillsides and valleys already have houses in them, and tunnels (regardless of if they’re road or rail) are expensive.
Seriously, why does this trope of saying “oh America can’t possibly, it’s such a big country” even exist, when the USA also has a road network despite being big and those roads are themselves generally much wider than Europe’s roads? It’s not like public transport is some special magic category that’s different from all the civil infrastructure the USA already makes, the only difference seems to be that “public” is a dirty word.
The real answer is that the US doesn't want public transit. I visited a rustbelt town several years ago, and a new mall had been sited specifically so that it would not be on the bus network: being accessible to the people who ride the bus was considered a liability for the businesses that would rent space in the mall.
More recently I visited a much nicer midwestern town which is planning an expansion of its bus network amd optimizing traffic lights for better bus flow. There is a new mall on the bus line. The difference is that 95% of bus riders in this second town are upper middle class college students.
To flip the argument: ok-to-good public transport is an Europe-wide thing. US is what, 2/3 of the population? Why don’t we ask if US needs to grow for public transport to scale?
Ah yes, because that’s the wrong dimension in the first place. Population density is the one that matters.
At the same time our government wants to increase the cost of public transportation [1] with the age old argument that it is too expensive compared to the cost of individual transportation.
While I don't have the numbers to analyze the costs it just doesn't make sense to me that a car with a single driver can be more cost effective than a bus, tram or train I guess the automobile lobby has convinced loads of my colleagues that individual transportation is price-comparable to public transport, even in Switzerland...
> doesn't make sense to me that a car with a single driver can be more cost effective than a bus, tram or train
This is a fascinating area to research. Of course there are trade-offs to model including a few such as: price of person's time waiting for next bus, time to go all around the mulberry bush instead of point to point, and hassles and personal safety in public places.
It would also make it take twice as long to drive from a ranch in Summer Lake, Oregon to the local grocery store in Lakeview to get groceries.
Some large swaths of the United States don't have public transit because of the expanse and also because of the use cases. People in the cities rely on people in these rural areas to grow food, so its not like you could wish everyone into the cities and solve the problem.
