Comment by josteink | Hacker News Reader

Comment by josteink | Hacker News Reader

Parent Full thread

> We knew about user testing, about UX. Git makes use of zero of those concepts. In fact, it seems to be actively hostile towards its users^.

I was with you all the way here, and then suddenly...

> We also had source control packages that were not only easier to use, but had more features: TFS let you

Suddenly you mention TFS as an example of something good. Mind blown.

TFS is absolutely among the worst "popular" version control systems I've worked with, and maintaining several branches and merging between them is pure hell.

In TFS a branch is something heavy which moves at tectonic speeds. Trying to maintaining agility in a world of TFS is just not viable.

> TFS let you put a lock on files that don't merge well, for example.

A "key" feature which more often than not is a source of problems you only have with TFS.

90% of the failed merges I've had with TFS has been because of its completely inadequate handling of binary files.

> Both TFS and Subversion allowed you to check-out only small portions of the repository.

This has nothing to do with Git specifically. This is a difference between centralized and distributed. If you want the benefits of distributed source-control, you'll have to pay the cost.

> I'd also question that Git is "universally respected".

Yes. Universally will obviously be easily disproven. I'd say "widely respected" instead.

> Suddenly you mention TFS as an example of something good.

You need to work on your reading comprehension. The only claim I made about TFS is that it has a feature (locking files) that Git doesn't.

I cited it as an example that Git has fewer features than its competitors. I never said anything about its quality.

> This has nothing to do with Git specifically. This is a difference between centralized and distributed. If you want the benefits of distributed source-control, you'll have to pay the cost.

Fine; but that's not the point.

The point is it's a feature that I want. And now that Git has seemingly taken-over the field of source control, I no longer have it. Nobody does. It's gone.

I'm not a fan of newer software having fewer features than older software.

> I cited it as an example that Git has fewer features than its competitors. I never said anything about its quality.

Fair enough.

> This is a difference between centralized and distributed... Fine; but that's not the point. The point is it's a feature that I want.

But file-locking is realistically just not implementable in a distributed source-control system. This sort of mechanism does only have a home in centralized architectures.

> I'm not a fan of newer software having fewer features than older software.

This may be a nitpick about the way you decided to express yourself, but just in case: Your math is wrong here.

You've had 1 capability you appreciate removed, while having tons of others added. That still yields you new software with more features, not fewer.

> But file-locking is realistically just not implementable in a distributed source-control system.

Ok. Then I guess it was a bad technical choice to pick that system if it prevents you from matching the features of your competitors, wasn't it?

I get the sense you're still missing my point here, but whatever.

> You've had 1 capability you appreciate removed, while having tons of others added.

Like what? The only one I'm aware of is "work offline". Which TFS also offers in the newer versions.

(Also: again, work on your reading comprehension. I talked about two capabilities that TFS and Subversion have that Git lacks.)

I'd like to hear about these "tons" of features Git provides over its competitors.

Git allows you to micro-manage your work by commiting often, and diffing against a previous known good state, with easy rollback an option all the way.

But this is not really friendly to issue in a PR for, so git also allows you to rewrite your commit history by squashing commits, by reordering commits, and basically cleaning up after the fact or before publishing for code-review, or public release or whatever,

If you decide that code you've written in one private repo logically belongs in another public one, you can create a new repo for the select files in your private repo which you want to share without losing version control information or any revision data.

Git has a flexible diff-engine and lets you for instance plug in pandoc for diffing word-processing files, letting you actually handle non-VCS friendly formats like MS Word through Git.

Git is modular and lets you plug in pretty much any thing you like.

And people like to, so there's modules for pretty much everything around.

Like VCS-bridges converting TFS and SVN repos to Git (and allowing you to merge seamlessly, while commiting back to the monolith).

Etc etc. The list goes on.

Git gives me the flexibility I need, to do pretty much anything I can imagine.

Except locking files. I'll hand you that one. It wont let me do that. But I can setup a central Git-server where I'll reject commits which tamper with pre-agreed "locked" files. So work-arounds obviously exist.

I'm not saying Git is perfect, but it works for me, for the needs I have. Which is more than I can say for TFS or SVN.

Reply on news.ycombinator.com