Git was made in, what, 2005. We knew about discoverability then. We knew about accessibility then. 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^.
We also had source control packages that were not only easier to use, but had more features: TFS let you put a lock on files that don't merge well, for example. Both TFS and Subversion allowed you to check-out only small portions of the repository.
Git has some nice things. It's generally fast, for example. It allows developers to work offline. But when the developer community apparently unilaterally chose to adopt it, we threw away a lot of good stuff, let's not forget that.
I'd also question that Git is "universally respected". I've worked with a great many programmers who found it just as unpleasant and unfriendly as I do. The reason people use Git is because other developers demand it as a condition of employment, not because it's enjoyable. In that respect, it's in the same class of application as, say, OracleApps or Lotus Notes.
---
^ Yes, someone's going to come in here and say, "well it's a professional tool for professionals therefore it's ok that it's difficult to use and hostile and not accessibility to people who can't use a CLI due to physical limitations because it's a professional tool for professionals.
Well.
Sony Vegas is a professional tool for professionals, and somehow it doesn't have even remotely the amount of usability problems Git does. So is Adobe Photoshop. So I don't buy that argument.
> 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.
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.
> Yes, someone's going to come in here and say, "well it's a professional tool for professionals therefore it's ok that it's difficult to use and hostile and not accessibility to people who can't use a CLI due to physical limitations because it's a professional tool for professionals.
Oh that's nonsense. First of all, because git is a CLI application you can easily build a GUI for it, and there are a lot of them for you to choose. You can't do the reverse, and good luck integrating your tightly coupled WinForms application with other tools.
Second, what "physical limitations" put people into a position where they can code but they can't use a CLI?
> Sony Vegas is a professional tool for professionals, and somehow it doesn't have even remotely the amount of usability problems Git does. So is Adobe Photoshop. So I don't buy that argument.
Multimedia artists are among the people who are most resistant to ever switch tools due to how much they have mentally invested into the complexities of their go-to application. Your example is far from good.
> Oh that's nonsense. First of all, because git is a CLI application you can easily build a GUI for it, and there are a lot of them for you to choose. You can't do the reverse, and good luck integrating your tightly coupled WinForms application with other tools.
While I agree his example (TFS) is rubbish and all that, I'll hand it to Microsoft that they've at least considered developers.
TFS source control comes with fully scriptable command line tools, not to mention a web-based API.
You can automate TFS-based processes. The WinForms are just there to make it more useable for end-users (and obviously because nobody else is going to bother making a GUI for this source-control system)
> Multimedia artists are among the people who are most resistant to ever switch tools due to how much they have mentally invested into the complexities of their go-to application. Your example is far from good.
And here we are talking about people not wanting to use IDE because how much they have invested in their favorite work flow mental model.
> First of all, because git is a CLI application you can easily build a GUI for it,
Actually you can't, because Git has features like "pre-commit hooks" and it's literally impossible to translate the output/messages of those into reasonable form for a GUI to consume (since it's just freeform CLI output text). The best you can do is simply echo them back to the user in a stupid text dialog box. You'll notice all Git GUIs either don't support pre-commit hooks at all (always commit with them set to disabled), or display the output of them using the lazy text dialog box method.
The other limitation, of course, is that since Git has no library, it's impossible for a GUI to be based on Git without it actually using Git CLI commands in the background. Which means if the Git CLI changes its commands, suddenly its broken all GUIs built off of it. (GUI clients generally "solve" this problem by shipping their own Git binary and using it exclusively, even if a newer one is on the same system.)
(It's funny that you mention WinForms. What Git does with its CLI commands is pretty much exactly equivalent to a WinForms app with business logic in the event handlers. Except where any WinForms developer would say, "why are you mixing up the UI and the program logic? That's a terrible idea!" apparently Git developers think it's great and double-down.)
It's impossible to build a truly quality GUI without the product being designed with that in mind from the start. Git wasn't. And there was simply no excuse for that in 2005.
> You can't do the reverse,
The correct way of writing an application is to put all the functionality into a library, then keeping your user interfaces separate from that library. So while you're right that you can't do the reverse (build a quality CLI from a GUI application), if the developers of Git had done their job correctly, you wouldn't have to. Git would have a core library that anybody could build any kind of user interface from.
> Second, what "physical limitations" put people into a position where they can code but they can't use a CLI?
Dyslexia. I can manage in an IDE with a large dependence on auto-complete, but I can't do a CLI.
Since I grew up on Macs and it's only relatively recently that crud like Git has been seeping into the Windows development scene, this had never been a limitation for me in the past. Worse than being user-hostile, Git makes me feel disabled in a way no other program has.
> Multimedia artists are among the people who are most resistant to ever switch tools due to how much they have mentally invested into the complexities of their go-to application. Your example is far from good.
I'm sorry my examples do not meet your exacting standards.
We also had source control packages that were not only easier to use, but had more features: TFS let you put a lock on files that don't merge well, for example. Both TFS and Subversion allowed you to check-out only small portions of the repository.
Git has some nice things. It's generally fast, for example. It allows developers to work offline. But when the developer community apparently unilaterally chose to adopt it, we threw away a lot of good stuff, let's not forget that.
I'd also question that Git is "universally respected". I've worked with a great many programmers who found it just as unpleasant and unfriendly as I do. The reason people use Git is because other developers demand it as a condition of employment, not because it's enjoyable. In that respect, it's in the same class of application as, say, OracleApps or Lotus Notes.
---
^ Yes, someone's going to come in here and say, "well it's a professional tool for professionals therefore it's ok that it's difficult to use and hostile and not accessibility to people who can't use a CLI due to physical limitations because it's a professional tool for professionals.
Well.
Sony Vegas is a professional tool for professionals, and somehow it doesn't have even remotely the amount of usability problems Git does. So is Adobe Photoshop. So I don't buy that argument.