Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is too hard

changelog.com

Post reply on HN
Print view View original

261–270 of 821 posts

Re: Git is too hard

#261

Post by mmm_grayons »

rjmunro wrote: post #212

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.…

This clearly isn't a popular opinion, but I may as well add it here: I like git. It's not that bad and not that hard to use. Occasionally I have to look up how to do something, usually involving git-filter-branch. But that's no surprise, because what I'm trying to do is usually inherently complex. I don't think a different interface would solve that. For most other stuff, git is simple and easy to use. It was a bit slow to learn, but most really good tools are (e.g. vim).

Re: Git is too hard

#262

Post by detaro »

thaumasiotes wrote: post #254
detaro wrote: post #237

Earlier quoted context omitted.

A "commit" doesn't contain a diff, it contains (references to) the blobs of the files at that state. Diffs are display-only, generated by comparing two full file states.

You really believe that git stores -- in full -- every version of a tracked file? Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space gone?

The git book explains the internals very well, so you can easily verify it for yourself. Files are referenced as objects in trees, which are pointed to by commits. editing a file creates a new object for it. (edited for tone)

Re: Git is too hard

#263

Post by TheUndead96 »

I see many comments saying that Git is still the best SCM system, which I agree with. Git can simultaneously be bad, and better than any other option available. To me Git has always seemed a little bit awkward. It works well when it works well. I think it it solving a hard problem. I don't think Git is the final solution though.

Re: Git is too hard

#264

Post by drran »

Joeri wrote: post #165
krageon wrote: post #127

Earlier quoted context omitted.

> I probably could sit down for a couple of days and fully understand how git works This means it isn't hard. If you are capable of understanding algorithms of any complexity you should be able to learn how to use git (and how much of it) without treading on ground that is dangerous for you to use. All of this "it's too hard" rhetoric is infantilising or coddling people who frankly shouldn't be trusted to code anythi…

Everyone starts at the ground floor. What would you tell a beginner who has to figure out 20 different technologies including git to get a basic web project going? Besides, nobody is arguing git needs to be made weaker, just that it would be nice if it had a more gradual learning curve. Easy things easy, hard things possible. If you can’t see how git is hard you’ve forgotten what it is like to be a beginner.

> What would you tell a beginner who has to figure out 20 different technologies including git to get a basic web project going?

We have the whole education system to deal with that. It's the same problem as in mechanics, chemistry, biology, etc.

Re: Git is too hard

#265

Post by thrwyoilarticle »

outsomnia wrote: post #234
thrwyoilarticle wrote: post #213

Earlier 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…

Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree with pull and don't know what fetch is. With history if you make a vcs mistake, or realize iteratively after pushing that corrections are needed, your worthless threshing around trying to fix it becomes part of your project log forever, instead of just pushing the…

I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. I see that as a fundamental difference in how the problem space is viewed and that they're stuck with a Github-first point-of-view. To me, even with merge commits, the history should be a statement of intent and treated as a first-class citizen, or even the primary output. Pushing a branch with threshing is like sending an email with visible backspaces.

Re: Git is too hard

#266

Post by oftenwrong »

I have often thought about what a truly intuitive, simple, easy, user-friendly VCS would look like. Git is fine for programmers, but what about non-programmers, or student-programmers? Would it be possible to make a VCS that my mother could use without sacrificing too much power?

One thing I would give up easily is decentralisation - a centralised model is more straightforward, and, for better or for worse, most people use Git in a centralised fashion.

Conflict resolution is one of the hardest version control tasks for beginners. Maybe it could be made easier by making the VCS AST-aware for more legible diffs, or by automating conflict resolution altogether with CRDTs or OT.

There were some interesting, very different takes on version control envisioned for darklang:

https://blog.darklang.com/how-dark-deploys-code-in-50ms/

Re: Git is too hard

#267

Post by vinceguidry »

Torvalds understands something extremely important about software, and that makes him uniquely suited to make deep, foundational, bedrock software projects.

The machine world is the machine world, and the human world is the human world. Git was built to match the problem space and not human intuition. This is why we still use it while no one who doesn’t have to uses cvs or svn anymore.

Of course it’s not easy for the beginning to intermediate coder to understand. It wasn’t written to solve that problem, it was written to support Linux kernel development.

What’s nice about git is that the interface stabilized years ago. It’s not going anywhere. Alternative git interfaces are everywhere, but only one is really any good, Emacs’s magit. There’s nothing stopping you from writing another one.

Or just do what the rest of us do when we encounter historically-entrenched ugliness. Learn its eccentricities and move on.

Re: Git is too hard

#268

Post by kadoban »

matthiasv wrote: post #214
bollu wrote: post #192

Earlier quoted context omitted.

While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor. We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does no…

While this sounds all nice it actually fails to model Git as it is. Git is an object database and its objects are blobs, trees and commits not diffs, so your premise is based on a misconception.

Git itself requires you be able to think of it as both models, diffs and snapshots. For example most uses of `git rebase` are clearer if your mental model while doing so are of diffs.

That only one is how it's implemented is besides the point really, until you get _quite_ low level.

Re: Git is too hard

#269

Post by Macha »

jariel wrote: post #117
dimgl wrote: 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…

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.

Re: Git is too hard

#270

Post by ricksharp »

I use vscode with Git Graph. It gives me a clear understanding of everything, allows me to manage branches easily, gives me access to every command I need, and even allows a great diff view between any commits.

Merge conflicts are easy to solve now and I never get lost in the complexity.

I use cli tools for almost everything, but Git Graph and vscode solves git for me. The only command I run in git cli is git clone or git unit.

Post reply on HN