4 ms·

as a noob trying to pick up coding just to experiment with some ideas, I always found Git to be surprisingly confusing. I feel that a lot of the command names

by spaceman_2020 4y ago

as a noob trying to pick up coding just to experiment with some ideas, I always found Git to be surprisingly confusing. I feel that a lot of the command names aren't very intuitive. Or am I just an idiot?

sedatk 4y ago
Git is confusing. Alternatives like Mercurial are way more intuitive and easier to use, but they lack popularity.
probably_wrong 4y ago
When it comes to git, I am firmly of the opinion that it's not you, it's them. Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost.
- CRConrad 4y ago
  > Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost. Yet another example of how, as so often in programming, the "KISS principle" ("Keep It Simple, Stupid") is deceptive: Simple isn't (at least not always) equal with easy. But yeah, with a more well-thought-out set of commands it would have been a lot easier for a lot of people. I think it's just simply (heh!) that it was released a tad too early, before anyone had thought more deeply about keeping the syntax orthogonal, and the world's been stuck with those choices (largely, choices not made in the first place) ever since, for backwards compatibility.
School-Cotton 4y ago
I don't know whether you're an idiot or not, but thinking git is confusing is certainly not evidence to that effect. Git _is_ confusing; it became the de-facto standard because it was the first free DVCS (and DVCSs solve lots of problems that were common to old non-distributed VCSs), not because its UI is particularly well-designed.
garyrob 4y ago
I agree with you. What I do is use the snippets from the blog post without particularly thinking about them!
jimbobimbo 4y ago
I have 20+ years of professional experience and I'm using git via Visual Studio or VSCode UI. I'm not feeling ashamed of that.
kadoban 4y ago
Git's command names, and UX in generaly, is its worst area. It's definitely not just you. Many professional software devs I work with still really have no idea how git works, they've just memorized the 3 or so commands they absolutely need and maybe how to recover when something out of the ordinary happens.
sureglymop 4y ago
I think what makes it more confusing is that the inner workings are almost too simple.. so one wonders why there are so many commands etc. Git is basically a linked list (if you have one branch) and a graph (if you have more than one branch). Then all you are really working with are pointers to certain nodes in that graph. In git terminology these nodes are called objects and there are different types of objects such as tree objects and commit objects etc. Objects are compressed with a library called zlib and are stored as files within the .git/objects directory, the file name is the hash of the decompressed object. But, back to the graph and the pointers to certain nodes. A branch itself is nothing more than a pointer either. You can look at the files in .git/refs/heads to see where they point. Now, what you do with git checkout is changing the node you currently view in the graph. If you make a commit you create a new node. Merging is nothing more than taking two nodes and creating a new node that is connected to both of them. The main problem i think is that concepts like branch, tag, commit etc are actually just overcomplicated abstractions of the much simpler graph nodes and pointers and are thus confusing.
jonnytran 4y ago
Git isn't designed for "noobs trying to pick up coding just to experiment". It also isn't really designed for solo developers as the OP is about. Git is designed for collaboration. Git's UI is absolutely unintuitive, especially coming from other version control software. But that's irrelevant. Everyone wants to use it because of the network effect. In terms of _why_ the UI is unintuitive, I believe it's because it intentionally exposes its internal representation. Unlike its predecessors like subversion, Git has infinite flexibility in terms of the workflow that teams of people can adopt. But the flexibility comes at the cost of learning how to use a distributed graph of commits. Personally, I never learned git by reading recipes of commands, like the OP. I only really grokked it by understanding how it works internally. This article helped me: Git for Computer Scientists https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/
- COMMENT___ 4y ago
  > Git has infinite flexibility in terms of the workflow that teams of people can adopt. IMO flexibility is just a meaningless buzzword used to describe overly complicated and poorly designed products. If a product has crappy UX, they just call it “developer oriented” and “flexible”. When I read about “flexibility” of a software product, I think that this product is of low quality. And that I will have to spend some time to make it work for me (hours? days? weeks? years?). To me as a user this flexibility does not matter at all. The product either works or it doesn’t. If it works, I don’t want to spend a career to learn its internals. I just want it to support my use case and give clear step by step instructions in its documentation. I better spend my time on something more important than exploring how this or another crappy software product is flexible.
- themadturk 4y ago
  Maybe git wasn't designed for experimenting noobs or solo developers, but it can certainly work for them. I'm not a coder, I'm a writer. I taught myself git, for myself. I collaborate with no one, and use only a few more features than the OP talks about (I push to and pull from remotes and branch occasionally). I love git.
marssaxman 4y ago
It's not just you. I have 30 years of experience coding and... hmm, probably 15 years of experience with git, at this point. I still think git is surprisingly confusing, and a lot of the command names aren't very intuitive. The engine is good, but the UI sucks. I wish the world had standardized on mercurial instead, but here we are.
- CRConrad 4y ago
  IMO the overwhelmingly biggest fuckup of the UI was / is the multiple overloaded meanings of "checkout", and the introduction a couple (three?) years back of "switch" and "restore" largely fixed that. Sure, there's still a lot of crap about it, but it's got a lot better. [Edit: tpyo.]
jimmygrapes 4y ago
It might be presumptuous of me, but maybe you're encountering the same issue I did/do: git as a tool doesn't seem mentally compatible with github /gitlab/etc. Locally, git almost makes sense. I make a change, I commit it to the tree of changes. I can roll it back, or branch it off, or merge branches, or restore from a previous point, and so on. It's when some kind of external repository gets involved where the model breaks down for me, especially if it's public/open source. Someone wants to help me fix a bug? Cool! They got my code from GitHub and modified it. Now they want their changes to be merged into my version. They submit a pull request. A what? They want me to pull their code into mine? Why isn't it called a push request, where they request permission to push their changes into my maintained repository? And so on.
- CRConrad 4y ago
  > Someone wants to help me fix a bug? Cool! They got my code from GitHub and modified it. Now they want their changes to be merged into my version. They submit a pull request. A what? They want me to pull their code into mine? Why isn't it called a push request, where they request permission to push their changes into my maintained repository? If you haven't given them push privileges to your repository, they can't push anything to it. That's why they have to request you to do it... And then it isn't a push, now is it? They're asking you to get code from their repo; that's a pull. The larger issue is of course that many people never use the git CLI with remote repositories: Far, far too many think that "GitHub is git." Dunno if that's what's happened in your case: You write, "They got my code from GitHub..." If they'd got it from a git repo on your server directly, their "pull request" would consist of an e-mail or something asking you to check out their code, and then you would do that in your repository by typing a command literally starting with "git pull ..."

sedatk 4y ago

Git is confusing. Alternatives like Mercurial are way more intuitive and easier to use, but they lack popularity.

probably_wrong 4y ago

When it comes to git, I am firmly of the opinion that it's not you, it's them. Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost.

CRConrad 4y ago
> Git is simple, but it takes a lot of experience to appreciate its simplicity. So don't beat yourself up, git is hard and it's okay to be lost. Yet another example of how, as so often in programming, the "KISS principle" ("Keep It Simple, Stupid") is deceptive: Simple isn't (at least not always) equal with easy. But yeah, with a more well-thought-out set of commands it would have been a lot easier for a lot of people. I think it's just simply (heh!) that it was released a tad too early, before anyone had thought more deeply about keeping the syntax orthogonal, and the world's been stuck with those choices (largely, choices not made in the first place) ever since, for backwards compatibility.

School-Cotton 4y ago

I don't know whether you're an idiot or not, but thinking git is confusing is certainly not evidence to that effect. Git _is_ confusing; it became the de-facto standard because it was the first free DVCS (and DVCSs solve lots of problems that were common to old non-distributed VCSs), not because its UI is particularly well-designed.

garyrob 4y ago

I agree with you. What I do is use the snippets from the blog post without particularly thinking about them!

jimbobimbo 4y ago

I have 20+ years of professional experience and I'm using git via Visual Studio or VSCode UI. I'm not feeling ashamed of that.

kadoban 4y ago

Git's command names, and UX in generaly, is its worst area. It's definitely not just you. Many professional software devs I work with still really have no idea how git works, they've just memorized the 3 or so commands they absolutely need and maybe how to recover when something out of the ordinary happens.

sureglymop 4y ago

I think what makes it more confusing is that the inner workings are almost too simple.. so one wonders why there are so many commands etc. Git is basically a linked list (if you have one branch) and a graph (if you have more than one branch). Then all you are really working with are pointers to certain nodes in that graph. In git terminology these nodes are called objects and there are different types of objects such as tree objects and commit objects etc. Objects are compressed with a library called zlib and are stored as files within the .git/objects directory, the file name is the hash of the decompressed object. But, back to the graph and the pointers to certain nodes. A branch itself is nothing more than a pointer either. You can look at the files in .git/refs/heads to see where they point. Now, what you do with git checkout is changing the node you currently view in the graph. If you make a commit you create a new node. Merging is nothing more than taking two nodes and creating a new node that is connected to both of them. The main problem i think is that concepts like branch, tag, commit etc are actually just overcomplicated abstractions of the much simpler graph nodes and pointers and are thus confusing.

jonnytran 4y ago

Git isn't designed for "noobs trying to pick up coding just to experiment". It also isn't really designed for solo developers as the OP is about. Git is designed for collaboration. Git's UI is absolutely unintuitive, especially coming from other version control software. But that's irrelevant. Everyone wants to use it because of the network effect. In terms of _why_ the UI is unintuitive, I believe it's because it intentionally exposes its internal representation. Unlike its predecessors like subversion, Git has infinite flexibility in terms of the workflow that teams of people can adopt. But the flexibility comes at the cost of learning how to use a distributed graph of commits. Personally, I never learned git by reading recipes of commands, like the OP. I only really grokked it by understanding how it works internally. This article helped me: Git for Computer Scientists https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/

COMMENT___ 4y ago
> Git has infinite flexibility in terms of the workflow that teams of people can adopt. IMO flexibility is just a meaningless buzzword used to describe overly complicated and poorly designed products. If a product has crappy UX, they just call it “developer oriented” and “flexible”. When I read about “flexibility” of a software product, I think that this product is of low quality. And that I will have to spend some time to make it work for me (hours? days? weeks? years?). To me as a user this flexibility does not matter at all. The product either works or it doesn’t. If it works, I don’t want to spend a career to learn its internals. I just want it to support my use case and give clear step by step instructions in its documentation. I better spend my time on something more important than exploring how this or another crappy software product is flexible.
themadturk 4y ago
Maybe git wasn't designed for experimenting noobs or solo developers, but it can certainly work for them. I'm not a coder, I'm a writer. I taught myself git, for myself. I collaborate with no one, and use only a few more features than the OP talks about (I push to and pull from remotes and branch occasionally). I love git.

marssaxman 4y ago

It's not just you. I have 30 years of experience coding and... hmm, probably 15 years of experience with git, at this point. I still think git is surprisingly confusing, and a lot of the command names aren't very intuitive. The engine is good, but the UI sucks. I wish the world had standardized on mercurial instead, but here we are.

CRConrad 4y ago
IMO the overwhelmingly biggest fuckup of the UI was / is the multiple overloaded meanings of "checkout", and the introduction a couple (three?) years back of "switch" and "restore" largely fixed that. Sure, there's still a lot of crap about it, but it's got a lot better. [Edit: tpyo.]

jimmygrapes 4y ago

It might be presumptuous of me, but maybe you're encountering the same issue I did/do: git as a tool doesn't seem mentally compatible with github /gitlab/etc. Locally, git almost makes sense. I make a change, I commit it to the tree of changes. I can roll it back, or branch it off, or merge branches, or restore from a previous point, and so on. It's when some kind of external repository gets involved where the model breaks down for me, especially if it's public/open source. Someone wants to help me fix a bug? Cool! They got my code from GitHub and modified it. Now they want their changes to be merged into my version. They submit a pull request. A what? They want me to pull their code into mine? Why isn't it called a push request, where they request permission to push their changes into my maintained repository? And so on.

CRConrad 4y ago
> Someone wants to help me fix a bug? Cool! They got my code from GitHub and modified it. Now they want their changes to be merged into my version. They submit a pull request. A what? They want me to pull their code into mine? Why isn't it called a push request, where they request permission to push their changes into my maintained repository? If you haven't given them push privileges to your repository, they can't push anything to it. That's why they have to request you to do it... And then it isn't a push, now is it? They're asking you to get code from their repo; that's a pull. The larger issue is of course that many people never use the git CLI with remote repositories: Far, far too many think that "GitHub is git." Dunno if that's what's happened in your case: You write, "They got my code from GitHub..." If they'd got it from a git repo on your server directly, their "pull request" would consist of an e-mail or something asking you to check out their code, and then you would do that in your repository by typing a command literally starting with "git pull ..."