RTFM.
Git is too hard
581–590 of 821 posts
Re: Git is too hard
#582With Git and most things, I place a lot of blame on the developers who say "it's easy" and go on to build complicated software.
Re: Git is too hard
#583> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…
I found the author's apparent belief that Git and Github are the same thing extremely annoying.
Github is a parasite.
Re: Git is too hard
#584Earlier quoted context omitted.
Single commands do many different things, options are inconsistent, e.g. -n does one thing for one command, and a different thing for others, lots of common tasks require complex sequences of commands, etc. It's pretty telling that there have been multiple attempts to write a saner CLI for Git.
I really don't see the issue. I've never struggled with git and it's already a muscle memory for me.
There have been many many blog posts about Git's terrible CLI. It's an established fact.
Re: Git is too hard
#585Earlier quoted context omitted.
Imagine SQL databases worked exactly like they do now under the hood, but instead of current SELECT/UPDATE/INSERT/DELETE they used like 15 different commands with at least 4 switches each. So instead of SELECT you'd have FETCH, PULL, CHECKOUT, CLONE, READ, PEEK, and OBSERVE. And each of them could in some cases also modify or even delete the data depending on the switches. Imagine there was no division between DML an…
SQL presents an static picture. It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. In your list of shout commands I don't see anything that could be used for merging? I guess the "language" of git could be tweaked to make it more consistent, but otherwise the problems it…
> It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history.
select ... as of timestamp;
I'm not arguing for using SQL as a git interface, I'm just saying git would greatly benefit from better interface based on some consistent and clear separation of concerns.
> the problems it is trying to solve are more complex than what could be dealt with in a SQL dialect.
It's not. SQL simplified A LOT of underlying details. There are dozens of types of indexes. There's partitioning and sharding. There's online backups. There are transactions - local and distributed ones. There's savepoints and rollbacks.
If SQL databases were like GIT - selects with joins using different indexes would have different syntax because "you need to understand the underlying structure" :)
Re: Git is too hard
#586Earlier quoted context omitted.
+1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interac…
> You might as well ask how to unsend an email. That is also a reasonable request. I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people. With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. I…
>I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer.
You don't understand because you think you're fighting computers but you're actually at odds with other human's desires.
If I pull your code, even if it was a mistake I don't want you to later rip the rug out from me and force me to figure out what happened from the history you deleted.
You can easily change the history technologically. You just force push what you want. The issue is that is usually disabled because it causes a lot of problems for everyone else on the team.
Re: Git is too hard
#587Git's plumbing is simple and intuitive. Git's UI has grown organically and is still not great for common tasks like undo, however they are working on it and it is slowly improving. For example, they've just added a restore command which should make it simpler to undo changes (git restore filename): https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things Things I'd also like to see improved: Undoing things locally sh…
Excellent ideas!
I agree with you on all fronts, exception git add --all && git commit. I don't believe those should be joined at the hip, because staging and committing should be two distinct actions/decisions. Defaulting to including everything would lead to too many human errors and would therefore be dangerous in my opinion.
A distinct flag like git commit --all -m "foo" might be OK in my book. Possibly even adding some git config --global commit.all [default|confirm] or something.
Then again, who am I?
Re: Git is too hard
#588Earlier quoted context omitted.
> The underlying technology of git is great, but the UX is terrible. I think it really comes down to a difference in philosophy in terms of learning how to use tools. In the past, one had to read the documentation to figure out how to use a tool. So, for instance, running git --help or git branch --help would give the information needed. Now having a what's considered an intuitive interface is expected, which is why…
I get what you are saying, and this makes sense, if you are in a situation where the problem your tool solves is so special and the target audience of your tool so involved that it makes sense to do things differently than the rest of the world. This is rarely the case. Sometimes at the end you get nothing but a wet handshake. Think about vim: it is cryptic, does everything different than everything else out there ,…
> Think about vim: it is cryptic, does everything different than everything else out there , but it gives you something in return.
The same could be said about git. For example, branching and merging is far better with it compared to previous VCS systems like SVN or CVS. And, like git, one had to read the documentation of those systems to have a good understanding about how to use them.
> I like reading manuals, but not for things that could have been totally obvious if somebody spent a split second thinking about how to communicate it clearly.
But should everything be totally obvious? For example, I doubt someone who hasn't read the documentation at some point could write a simple hello world program in most programming languages without making an error.
Re: Git is too hard
#589Earlier quoted context omitted.
It's evident that you think requiring basic competence is toxic, but you don't really compel me to feel differently. You have told me what I think is the case is toxic, wrong, disgusting and harmful. I now know you feel strongly about this. I don't hugely feel like seeing things from your point of view because the only thing you've really told me that might change my mind is that you lose people when you require a ba…
Not the person you're responding to, but I have my own two cents: Saying "basic competence" is horrifically abusing language here. Git is a glorified save/share/undo tool, demanding people spend several days reading the manual is an absolute caricature and yet you're seriously saying that. The reason people are mad at you is that people have lived experience of the interface sucking and failing to do the job an inter…
You're not the first one to say that it's hard to use right and I agree with that. This is true for a lot of powerful tools. At the end of the day, what is intuitive is what you have used a lot. If you're using a tool that fits an entirely different paradigm from what you are normally used to, it's going to be unintuitive. It's fair to say this frustrates everyone, especially in the beginning.
All that being said, this is not a reason to then take the next step and claim that basic competence in what is today an essential tool is optional. It is necessary and to work well you must know it well, otherwise the frustration you point out will be part of your life every day. As opposed to something that you live through and say goodbye to.
The fact that everyone is taking this as toxic or willfully oblivious is as far as I'm concerned infantile. It has nothing to do with "being a real man" (whatever that means to you), it has something to do with having the maturity to realise that you are making your own problems.
That is not to say we cannot build a better tool. Perhaps we can! Up until this point I have not seen it done without losing something else in turn.
Re: Git is too hard
#590I went from typing everything out to using aliases via Oh My Zsh.