4 ms·

If I had a dollar for every time someone complains about how git is unfriendly, I'd have enough to buy Twitter. I've been using version control systems since C

If I had a dollar for every time someone complains about how git is unfriendly, I'd have enough to buy Twitter. I've been using version control systems since CVS and I've found git the easiest and most sensible thing to use. Admittedly, some of the commands reflect internal data structures and concepts rather than what a user would want to do but that's just a learning curve issue. To address specific points. 1. Of the 157 commands, there are maybe 10 or so that one would need on most days and maybe 5 or 6 others when things go awry. Perhaps another half dozen for specific workflows but that's it. How many times do people use git daemon or git instaweb or git fsck? Why are these listed there? I do git trainings and teach a handful of commands in half a day which are sufficient to get people started. 2. The index has been extremely useful to me when I code for a while and then later need to commit only some files or parts of files into separate commits. This is a "good thing". The workflow which the author is suggesting would be like a "git commit -am ... && git push" which is not ideal 3. There are two destructive commands. git checkout and git reset when you've not committed. These two can discard uncommitted code in the working tree and you'll lose them. Once you've committed, it's possible to undo almost anything using the reflogs. They're very useful and worth learning how to navigate and use. Even rebase --hard can be undone by switching to a previous reference. I think this is a deliberate decision. git is a power tool that sacrifices protecting the user from mistakes to give the user fine grained power over a project. A tool that hides these things from a user and tries to wrap the whole thing in a veneer of user friendliness might be good if engineered properly but my feeling that is that it wouldn't be worth the sacrifice. Highflux itself advertises several things like " Automatic commit on every editor save." which I'm not sure are good ideas. I hit save repeatedly while working. Each one of those saves is not meant to be a commit.

ozim 4y ago
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - this quote of Bjarne sums it up. GIT complainers should write their own DVCS :) let's see how many people will use it .. if it would really be better everyone would use it.
beebmam 4y ago
Agree! Doing basic operations with git really isn't hard at all. For most people, they don't need to worry about how git actually works, they just need to learn how to clone, checkout, create branches, push, and rebase/merge (basic versions). It takes like an hour, tops, to learn virtually anything you need unless you're responsible for an organization's repositories. Unless you're using submodules. Which is one big reason people hate them usually!
sorokod 4y ago
If I had a dollar for every time someone complains about how git is unfriendly, I'd have enough to buy Twitter. Worth to pause and consider the implication of this statement.
112233 4y ago
Oh, so much to rant about! Let me address specifically the "git is a power tool" part. Actual dangerous power tools used in industry have a lot of safety requirements, and even may require license to operate. You do not put lathe in your lobby and expect everyone to know how to use it properly. If there would be qualified git technicians, that would take care of all git related activities developers need, I don't think there would be so much complaining. However, what actually is happening, is dev, still being absorbed in his project, suddenly needs to confront index, stage and cache (these three are one, yet are not the same), figure out whic of the soft hard mixed reset, no, revert to use. So I want to put my local changes in new branch? Use "git checkout"! But checkout was the dangerous one!? And you "cp -a" your whole dir, because you are afraid to mess up...
RichardCA 4y ago
There is a characteristic in software that there is no good word for, it's the quality of unfolding gracefully and allowing for a gentle learning curve. BASIC had it in the old days, some would say Perl and shell programming had it too. Git is emphatically not like this. The default use case is to teach a novice how to add/commit/pull/push and strand them there. If they are enterprising they will figure out the more advanced stuff on their own, or ask a more experienced user to apply the proper pedagogy and explain the hidden elegance of the SHA-1 + DAG data model. And it's no coincendence that these "more experienced users" are often the same ones who cut their teeth on command line at some point in the past (and probably know some Perl and shell, and maybe even learned BASIC in the distant past).

ozim 4y ago

"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - this quote of Bjarne sums it up. GIT complainers should write their own DVCS :) let's see how many people will use it .. if it would really be better everyone would use it.

beebmam 4y ago

Agree! Doing basic operations with git really isn't hard at all. For most people, they don't need to worry about how git actually works, they just need to learn how to clone, checkout, create branches, push, and rebase/merge (basic versions). It takes like an hour, tops, to learn virtually anything you need unless you're responsible for an organization's repositories. Unless you're using submodules. Which is one big reason people hate them usually!

sorokod 4y ago

If I had a dollar for every time someone complains about how git is unfriendly, I'd have enough to buy Twitter. Worth to pause and consider the implication of this statement.

112233 4y ago

Oh, so much to rant about! Let me address specifically the "git is a power tool" part. Actual dangerous power tools used in industry have a lot of safety requirements, and even may require license to operate. You do not put lathe in your lobby and expect everyone to know how to use it properly. If there would be qualified git technicians, that would take care of all git related activities developers need, I don't think there would be so much complaining. However, what actually is happening, is dev, still being absorbed in his project, suddenly needs to confront index, stage and cache (these three are one, yet are not the same), figure out whic of the soft hard mixed reset, no, revert to use. So I want to put my local changes in new branch? Use "git checkout"! But checkout was the dangerous one!? And you "cp -a" your whole dir, because you are afraid to mess up...

RichardCA 4y ago

There is a characteristic in software that there is no good word for, it's the quality of unfolding gracefully and allowing for a gentle learning curve. BASIC had it in the old days, some would say Perl and shell programming had it too. Git is emphatically not like this. The default use case is to teach a novice how to add/commit/pull/push and strand them there. If they are enterprising they will figure out the more advanced stuff on their own, or ask a more experienced user to apply the proper pedagogy and explain the hidden elegance of the SHA-1 + DAG data model. And it's no coincendence that these "more experienced users" are often the same ones who cut their teeth on command line at some point in the past (and probably know some Perl and shell, and maybe even learned BASIC in the distant past).