4 ms·

I guess this will come off kinda... douchey? But I just don't find Git to be that hard. I know there's a lot of complexity there, but I find that 95% of the tim

I guess this will come off kinda... douchey? But I just don't find Git to be that hard. I know there's a lot of complexity there, but I find that 95% of the time I'm just git add -p or git add . and then committing. Every once in a while I'll do a rebase, and that's the most complex part of Git that I use with any frequency. I remember when I first was introduced to Git I found it confusing, so I'm sympathetic to newbies who have to cross over the learning curve, but I think the main day-to-day Git operations just aren't that much to learn. What is it about Git that people find so difficult, even after using it for a while?

squeaky-clean 4y ago
95% of hit usage is fairly easy, yeah. But that other 5% can be extremely difficult.
randomsearch 4y ago
The UI is inconsistent and unintuitive.
- eru 4y ago
  That's true. But they are working on this. Slowly. Eg compare https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch to git checkout. https://www.infoq.com/news/2019/08/git-2-23-switch-restore/ https://www.infoq.com/news/2019/08/git-2-23-switch-restore/
- agentwiggles 4y ago
  I won't disagree with that, but idk. Once you understand the basic operations everything weird is a Google away. I'll admit that Git is the only VCS I've spent any time with, so maybe I just don't know how much better it could be. But I've almost never had an issue with Git where I actually lost code. And anytime I'm doing something dangerous, I just make a backup copy of the directory in case I screw up irrevocably. But even if I'm doing something nasty, the reflog is there, and the cases where I've need to use my backup copy are very few and far between.
  - IshKebab 4y ago
    > Once you understand the basic operations everything weird is a Google away. Yes that's true, but what you've probably forgotten is that understanding the basic operations is way way harder than it should be thanks to Git's terrible CLI, nomenclature and general UX. I would also argue that the lack of an obviously good GUI makes it quite a lot harder for beginners, and the attitude that a lot of HN commenters have that you shouldn't use a GUI, despite Git being an obviously visual thing. Btw any beginners reading this, I would recommend Git Extensions. Terrible name which led to me not trying it for ages, but it's actually one of the best. In particular it lets you browse the repo at every commit which is something that makes it way clearer what Git is doing.
  - jfk13 4y ago
    > almost never ... actually lost code That seems like one of the absolute basics. "Almost" never...? > I just make a backup copy of the directory in case I screw up irrevocably If you really felt you could trust your source control system, that shouldn't be needed, and... > the cases where I've need to use my backup copy ...should be nonexistent.
    - copperx 4y ago
      I agree. If losing code with Git is even a remote possibility, then you're "holding it wrong" indeed.
      - Dylan16807 4y ago
        There are multiple ways to accidentally overwrite or delete a file that wasn't committed yet. There are also situations where you need to use these commands and you're not ready to commit everything. The safe way to handle this is generally making a stash commit and immediately applying it, but if you don't know that, or don't think to do that first, the result can be data loss. Git is very careful about commits but if you never staged something then git can be ruthless.
    - agentwiggles 4y ago
      I guess what I'm trying to express is that even in the rare case I'm doing something fancy with git making sure I don't lose anything is trivial. I can think of exactly one time I actually lost code and I was doing ill advised reflog fuckery. I take your point, but I stand by my opinion that in virtually all normal usage, git just isn't that hard. YMMV.
softwaredoug 4y ago
I don't find it _hard_, but it is very _unopinionated_ So if you mix up one kind of workflow with another, you can really shoot yourself in the foot. There's people that have a merge-based workflow, a rebase-based one, more advanced projects (Linux kernel) have something more bespoke. Getting used to one project, then using those practices in another, can really mess you up.
opsy_ 4y ago
I think (from working with git newbies) the core difficulty is not understanding the Git's fundamental data structure. If you have computer science training / data structure understanding, once you realize (1) Commits are nodes in a graph (2) branches are just pointers to a specific node, you're off to the races. From there, I find it straightforward to conceptualize all the different commands. Commit/push/reset/merge/pull/rebase/etc are all just different graph manipulations. There's usually multiple ways to achieve the end graph you want. If you don't understand the data structure, you have no good mental model and it's just a series of ritual. If something goes off the ritual path, you're in trouble.

squeaky-clean 4y ago

95% of hit usage is fairly easy, yeah. But that other 5% can be extremely difficult.

randomsearch 4y ago

The UI is inconsistent and unintuitive.

eru 4y ago
That's true. But they are working on this. Slowly. Eg compare https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch to git checkout. https://www.infoq.com/news/2019/08/git-2-23-switch-restore/ https://www.infoq.com/news/2019/08/git-2-23-switch-restore/
agentwiggles 4y ago
I won't disagree with that, but idk. Once you understand the basic operations everything weird is a Google away. I'll admit that Git is the only VCS I've spent any time with, so maybe I just don't know how much better it could be. But I've almost never had an issue with Git where I actually lost code. And anytime I'm doing something dangerous, I just make a backup copy of the directory in case I screw up irrevocably. But even if I'm doing something nasty, the reflog is there, and the cases where I've need to use my backup copy are very few and far between.
- IshKebab 4y ago
  > Once you understand the basic operations everything weird is a Google away. Yes that's true, but what you've probably forgotten is that understanding the basic operations is way way harder than it should be thanks to Git's terrible CLI, nomenclature and general UX. I would also argue that the lack of an obviously good GUI makes it quite a lot harder for beginners, and the attitude that a lot of HN commenters have that you shouldn't use a GUI, despite Git being an obviously visual thing. Btw any beginners reading this, I would recommend Git Extensions. Terrible name which led to me not trying it for ages, but it's actually one of the best. In particular it lets you browse the repo at every commit which is something that makes it way clearer what Git is doing.
- jfk13 4y ago
  > almost never ... actually lost code That seems like one of the absolute basics. "Almost" never...? > I just make a backup copy of the directory in case I screw up irrevocably If you really felt you could trust your source control system, that shouldn't be needed, and... > the cases where I've need to use my backup copy ...should be nonexistent.
  - copperx 4y ago
    I agree. If losing code with Git is even a remote possibility, then you're "holding it wrong" indeed.
    - Dylan16807 4y ago
      There are multiple ways to accidentally overwrite or delete a file that wasn't committed yet. There are also situations where you need to use these commands and you're not ready to commit everything. The safe way to handle this is generally making a stash commit and immediately applying it, but if you don't know that, or don't think to do that first, the result can be data loss. Git is very careful about commits but if you never staged something then git can be ruthless.
  - agentwiggles 4y ago
    I guess what I'm trying to express is that even in the rare case I'm doing something fancy with git making sure I don't lose anything is trivial. I can think of exactly one time I actually lost code and I was doing ill advised reflog fuckery. I take your point, but I stand by my opinion that in virtually all normal usage, git just isn't that hard. YMMV.

softwaredoug 4y ago

I don't find it _hard_, but it is very _unopinionated_ So if you mix up one kind of workflow with another, you can really shoot yourself in the foot. There's people that have a merge-based workflow, a rebase-based one, more advanced projects (Linux kernel) have something more bespoke. Getting used to one project, then using those practices in another, can really mess you up.

opsy_ 4y ago

I think (from working with git newbies) the core difficulty is not understanding the Git's fundamental data structure. If you have computer science training / data structure understanding, once you realize (1) Commits are nodes in a graph (2) branches are just pointers to a specific node, you're off to the races. From there, I find it straightforward to conceptualize all the different commands. Commit/push/reset/merge/pull/rebase/etc are all just different graph manipulations. There's usually multiple ways to achieve the end graph you want. If you don't understand the data structure, you have no good mental model and it's just a series of ritual. If something goes off the ritual path, you're in trouble.