Most active commenters
  • wruza(3)

←back to thread

1062 points mixto | 20 comments | | HN request time: 0.786s | source | bottom
Show context
scrapcode ◴[] No.42942555[source]
I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.
replies(6): >>42942641 #>>42942672 #>>42942768 #>>42943372 #>>42950299 #>>42954886 #
1. 20k ◴[] No.42943372[source]
Honestly, 99% of the pain of git is simply because people use it through the CLI. If you use tortoisegit or a visual tool, you don't need to worry about any of this because its self explanatory, and it becomes trivial to use

Learning git like this is honestly just hampering yourself

replies(10): >>42944314 #>>42944637 #>>42944837 #>>42944918 #>>42946240 #>>42946386 #>>42946705 #>>42948452 #>>42948599 #>>43014598 #
2. wruza ◴[] No.42944314[source]
I’ve seen tortoise users break their repo, struggle to understand the issue and then push it through, making it everyone’s problem. Git language is screwed, you cannot unscrew it with a right-click gui because you basically click some latin-looking hieroglyphs that you don’t know either way.
replies(1): >>42945358 #
3. pknerd ◴[] No.42944637[source]
It is still better than (As)SVN
4. crabbone ◴[] No.42944837[source]
Not at all. Not in the least.

The worst part about Git is the bad defaults. Seconded only by mismanaged storage. Or maybe being designed for the use-case most of its users will never have. Or maybe horrible authentication mechanism. Or maybe the lack of bug-tracker or any sensible feedback from its developers.

None of this can be helped by the GUI. In fact, beside Magit, any sort of front-end to Git I've seen is hands down awful and teaches to do the wrong thing, and is usually very difficult to use efficiently, and mystifies how things actually work. But, even with Magit, I'd still advise to get familiar with CLI and configuration files prior to using it: it would make it easier to understand what operations is it trying to improve.

replies(1): >>42945633 #
5. ◴[] No.42944918[source]
6. globular-toast ◴[] No.42945358[source]
I highly doubt tortoise or any tool can "break" a repo. This might be a sign that you don't understand git either. Now I'm sure it can lead to people who don't know what they're doing doing the wrong thing, but if they're allowed to push somewhere and make it someone else's problem, that's not their fault. They've been forced to use git, so there should be someone else who actually understands git.
replies(2): >>42945665 #>>42949114 #
7. maccard ◴[] No.42945633[source]
I use the IntelliJ family of IDEs and the number of times I’ve had to reach for the cli for day to day use is incredibly close to 0. It handles GitHub auth, PR’s, branching and merging, rebase, and local branch switching pretty much effortlessly
replies(1): >>42950926 #
8. _puk ◴[] No.42945665{3}[source]
Ah, we're holding it wrong. Got it.
9. agumonkey ◴[] No.42946240[source]
depends, you could live on a UI for a start, but script git cli gives you very high speed.. it's kind of a timeline database for your code
10. zelphirkalt ◴[] No.42946386[source]
Learning it like this makes one learn the concepts though and build something closer to an actual understanding. I have seen people struggle with understanding what git does or with making fine grained commits or mostly atomic commits a lot, especially GUI users, because many of them do not have the underlying concepts understood well enough.
replies(2): >>42946671 #>>42957026 #
11. tonyedgecombe ◴[] No.42946671[source]
I think you could use a CLI and still not really understand the core concepts.
12. jeroenhd ◴[] No.42946705[source]
I disagree. Version control is kind of a pain, you need to understand some of the underlying concepts or you'll break your git repo in spectacular ways.

The command line isn't that hard to use if you've ever used the command line before. Beginners trying to learn git and command line at the same time (which is very common) will get utterly confused, though, and for a lot of beginners that's the case. The only difficult part with git over the command line is fixing merge conflicts, I'd recommend anyone to use any IDE rather than doing that manually.

No IDE will be of any help for getting back to normal when you get into a detached HEAD state, which IDEs will gladly let you do if you click the right button.

13. nextlevelwizard ◴[] No.42948599[source]
I feel like when people talk about replacing programmers with AI they are talking about people who can’t even grok git
14. wruza ◴[] No.42949114{3}[source]
“Break” doesn’t mean repo integrity corruption. It means that you try to merge a branch, and it shits itself with hundreds of conflicts that shouldn’t appear and/or has changes that may partially revert the progress made by other merges.

if they're allowed to push somewhere and make it someone else's problem, that's not their fault

What? This made zeroest sense of the day. Like, I should walk to their desk and check if a feature branch is okay to push or what?

replies(1): >>42950162 #
15. globular-toast ◴[] No.42950162{4}[source]
Usually people make pull requests.
replies(1): >>42950428 #
16. wruza ◴[] No.42950428{5}[source]
Yep, with a branch they pushed into. I guess you're ignoring the same context as another commenter elsewhere, probably because your workflow is restricted only to modes that git "supports".
17. crabbone ◴[] No.42950926{3}[source]
In my experience, people who use Intellij family of IDEs have very limited understanding of how anything in their computers work. They are hired to "write Java" or something similar, and beside "writing Java" they know virtually nothing and aren't expected to know anything.

I used to work for a large company in the ops department, where a significant portion of my day was spent walking between cubicles and fixing the dev. environment of Intellij IDE programmers. Most of them didn't even know how to find the project they worked on in the filesystem w/o using their editor. The tantalizing task of opening a file with unknown extension was way too much to ask etc.

They would often mess up something in the version control too, using Intellij integration tools, which are really, really bad. But, I don't know whom to blame in this instance. Both the user and the tool were of extremely low quality.

So, if, eg. their Maven build had some sort of an interaction with Git, and they messed up something in their local repository, all work would come to a grinding halt, because they had no idea how to even begin to understand what went wrong.

It's a kind of job where you begin to lose faith in humanity very quickly :D

18. 20k ◴[] No.42957026[source]
Knowing how to do it through the CLI adds nothing to your understanding of the concepts though. Its just whether or not you have to remember an opaque CLI command, or you get a UI to click
replies(1): >>42961346 #
19. zelphirkalt ◴[] No.42961346{3}[source]
I think it depends. If the GUI tooling is exposing you less to the actual concepts and builds new concepts on top, that simplify things, then that will hamper a new user's understanding of the underlying concepts. Of course, it is not the CLI usage itself, that is the key here, but the usage of a tool, which exposes you to the actual concepts of git, and the most common tool like that is, of course, the default git command line interface.
20. ycombinator_acc ◴[] No.43014598[source]
Git GUIs like Turtois, Cracken, Lens, VSCode's Source Control are opinionated and for some reason all do weird stuff under the hood. If you look at the commands being run, a simple action or click in the menu results in a combination of 2, 3, 4 git commands that often resemble nothing like how I (and I imagine most people) would do it in CLI.

This is just asking for trouble.