Hacker News Reader

Comment by taoistextremist | Hacker News Reader

I'm planning on making a hard push for git on the team I just joined (that isn't using any VCS). This and OP are going in my bookmarks.

View on HN

> I'm planning on making a hard push for git on the team I just joined

You mean a force push. `git push --force` is one of my favorite commands. I've aliased `git yolo` to `git push --force --no-verify`.

Maybe I ought to also insist I build git from source and scrub any reference to --force from it.

Use Gitlab and you can at least prevent --force push with permissions.

GitHub does this too.

--force-with-lease is usually the better option; it makes sure nobody pushed anything since the last time you fetched from the remote.

If they have, you can fetch, see if you still want to overwrite that branch, and if so run it again.

>git yolo

I hope you do not work on missiles or on passenger aircrafts!

I'm genuinely curious how they manage source without any VCS. Is it just a bunch of zip files for old versions?

No judgment, nobody is born knowing this stuff, just that I'm surprised to hear this is still out in the wild.

We SSH onto a server to do work and it seems we just make folders wherever for our individual projects. They do (nightly, I think) backups which is sort of a rudimentary version control. And while I'm told it exists, it seems the "dev" version of their website isn't used, so they just kind of add in their changes live; definitely a risky environment. They've had a small team for a while and most of their applications could run relatively in isolation from others, so they could get away with it, but they're looking to grow so I'm trying to push this stuff.

Yeah the "right way" to do VCS is definitely a lot of overhead for a team like that, but by the time you need to scale up (and by "up" I mean 3-6 people total who are committing code multiple times daily?) the business is likely so busy it's a HUGE uphill battle to implement something like that, especially since most of the people who let an environment like that happen will likely not be super familiar with Git/hg/TFS/whatever.

I dunno if I'd agree that it's a lot of overhead, for what you get back. Hell I'm a one-man team right now and I'm using source control. Some of my little experiments go horribly awry. Some of my deletions are a bit too aggressive/arrogant. Sometimes you need to diff shit. Version control frees me to be bold.

Agree with you here. I use git for literally every coding project, even my quick practice folders. I haven't had an "oh-shit" moment from losing anything in like 5 years, back when I was still learning git.

When I started working for the government (2010) it was .backup, .bak, .new, .newNEW, new-JIM, .20100910... all on one guy's workstation. Luckily Gitorious landed within months. (better than nothing)

i know that some shops do nightly tape backups of the harddrive on the fileshare and consider that sufficient for version control. the theory is "developers don't have to learn a new tool and we will never lose more than one day's worth of work".

these shops don't understand the benefits version control offers when it comes to code review and maintenance patches on old versions of the software, or vendor-specific streams for your software.

My friend works for a small company that doesn't use a VCS. They just make a new folder and copy the project into it every once in a while.

Everybody that is not a programmer (or otherwise IT/technical) doesn't understand version control at all. So as other commentators have said, their idea of version control is to save the file with a different name, a different extension, etc.

I have seen it as files on a shared drive. I have seen it as files on a sharepoint drive. I have seen it as files inside of an SVN repository.

No, there's a lot of decent project managers, lawyers, etc, who understand something called revision control, which has much the same job in the real world for managing complex pieces of work, specs, etc...

I remember joining a company where the official build was cut from whatever was on the engineer's PC at the time, since that PC was the only one set up that could build the software. No documentation, no formal bug tracking, no source control, very infrequent backups that were probably never tested. It was basically a "0 on the Joel Test" shop. This software was for embedded aerospace applications too (however not safety-critical where DO-178B would apply, thank god).

Reply on news.ycombinator.com