Live data from Hacker News

Git is too hard

changelog.com

411–420 of 821 posts

Re: Git is too hard

#411
post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

I think there are many aspects of Git that are obscure/error-prone regardless of how well you understand its implementation.

For example, the concepts of "ours" and "theirs" when looking at changes depends on the current operation mode (rebase vs merge).

Merging is unsafe-by-default, because it auto-merges even if both branches have modifications to the same file, and there is no guarantee that the resulting file is correct.

There are numerous ways to collaborate on a git repo, with vastly different performance/usability implications, none of which is obvious when you start up (merging remote into local, rebasing local onto remote, squashing local commits; patches vs pushes).

Not to mention that, for teams that work with a centralized remote repo, the whole concept of local tracking branches adds mental overhead for nothing, and extra work every time you want to push a change to a remote branch. You have to first pull, even if your changes and the remote ones don't touch the same files. Which of course means that, if you had a dirty worktree, you actually need to run 3 commands - one to stash your changes, one to pull, the actual push, and now an unstash.

Re: Git is too hard

#412
post #317

Earlier quoted context omitted.

You should, or do you just merge updated remote branches into your stale local branches? A lot of new developers seem to do that here until we explain to them how it messes up the history.

> do you just merge updated remote branches into your stale local branches? Every single developer I work with (or have in the last 8 years) does this. "Messes up the history" ? The merge commit describes that there are uptaken changes from the "main" branch. It doesn't seem to be a problem in practice.

It's also not a problem for me, because I squash the commits on merge to master or other remote branch.

Re: Git is too hard

#413
post #269
post #117

Earlier quoted context omitted.

Git is I think objectively more complicated any other popular VCS, simply due to the fact it has much more in the design model. It's also more powerful. But the tradeoff is ugly within the context of the nature of the UI. Git is like C++, it has a lot of features, the UI is not well thought out and it creates countless corner cases. Git was not designed to focus on the core cases, making things simple. Git is one of…

Git is more popular because Github used Git and Github was better than google code or sourceforge. Bitbucket got like 80% of the way there but was always a few steps behind. Had bitbucket taken off rather than github (which is much more to do with the web UI and network effects than the underlying VCS), we'd all be using hg now.

I don’t believe this. If you manage to use the git CLI you’re not put off by bad bitbucket UI.

My explanation would be:

Git won because it was used for Linux and because it was fastest where it mattered.

Re: Git is too hard

#414
post #317

Earlier quoted context omitted.

Ya, I'm the opposite, I never use rebase. Horses for courses...

You should, or do you just merge updated remote branches into your stale local branches? A lot of new developers seem to do that here until we explain to them how it messes up the history.

I've been doing that for years, and it's never messed up the history.

Re: Git is too hard

#415
The UX design of git is horrible, granted. To me this article read as "I want a GUI", while having some good points.

For example on knowing branches having local and remote versions, "because why would they"..they would because if they want to use the tool effectively then they need to know how it works. This is the same reason I learned how to use git prune. Would I ever use it on production code without a backup? No.

A GUI is not the solution, because a GUI can never equal the expressiveness and capability of skill combined with a parcity of input provided by the command line. If it did then the complexity of using the GUI would be just as hard, or harder, than the command line interface. However, there are many who do not need more than basic Git. Those can be served by a simple GUI, or by pre-provisioned Git aliases with documentation of what those aliases do.

I still dislike a GUI because I have had a number of people come to me to fix things on a team that used SourceTree and accidentally did something horrible, either because their finger slipped or because they didn't realize what they were doing and the GUI made it too easy to do it.

All powerful tools should have a simple version and a complex version. Git is extremely powerful, but has no simple version for everything.

What helped training new people was telling them to think of git like a complex copy operation across computer boundaries, and explaining the commands in terms of that. Once they've gotten comfortable with the basics then you can explain how it differs from copy (and it does, greatly).

Re: Git is too hard

#416
post #368

Earlier quoted context omitted.

I use an x86 CPU every day for work and I have no idea how it works in detail, and thanks to the magic of separation of concerns I don't have to (perhaps apart from a few specific things like vecorizing instead of loops that I really do need to know about). Git demanding a large chuck of user mindspace isn't an advantage for git, it's a signal that git is bad and needs replacing.

So do interpreters, compilers, package managers, virtual environments, build systems, CI systems, test frameworks, targets, hosts. Your code doesn't exist in isolation, you need to grok how it works with the codes others have written and will write.

But for each one of these, the less I have to know about its internals, the better.

The ideal option for each of these things is that it "just works". When you have to think about the internals of your package manager or your CI or your virtual environment, that's a flaw in it, not a reason to celebrate.

Re: Git is too hard

#417
post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

Mental model to use SVN for example was quite simplified.

No connection to the server no committing - no confusion about local vs remote. Branching only on the server, merging totally useless - no branches, no merging, no conflicts. Want to have your local development versioned - zipfile + date time.

I would never go back to that, but from people complains some might want to.

Re: Git is too hard

#418
Git is indeed hard, but it’s also far too easy to screw something up, sometimes irreversibly. Before I became much more competent with Git, I used to spend far too much time trying to figure out how to undo or fix things. My strategy eventually became “just be extremely careful with everything”. That said, I have learned to judiciously use GUI tools such as those built into IDEs, but I have had to make conscious efforts to understand the commands they’re using underneath.

Let’s also not forget that version control — and any kind of synchronization — in general is hard.

Re: Git is too hard

#419

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squashing, fast-forwards, tags.

You have to understand a lot of things before you can somewhat comfortably use git, much more than something like P4.

Re: Git is too hard

#420

The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…

I don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

[deleted]
Post reply on HN