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

211–220 of 821 posts

Re: Git is too hard

#211

Post by dijit »

rakoo wrote: post #167

> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…

Weird question; have you looked at perforce?

My previous and current company use perforce but many people (often those who recently join) are decrying that perforce is less elegant than git, but, realistically and based on your own criteria it would be "better" for the connected case.

I'm personally a big fan of 'offline/local-first' being a thing, but I'm a sysadmin not a developer.

Re: Git is too hard

#212

Post by rjmunro »

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. The trick to learning is to always have `gitk --all` or a similar viewer open in another window.

Also instead of `git add` / `git commmit`, use `git gui`, but for most other things stick to the CLI.

Having said that use a GUI, github desktop is terrible. It tries to make things easier and as a result takes you away from git's standard terminology, so it's impossible to understand what it does.

Something I found teaching other people is it helps a lot if you haven't learnt SVN before.

Re: Git is too hard

#213

Post by thrwyoilarticle »

rakoo wrote: post #167

> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=…

+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 interaction with git is a disaster.

Regardless, there's no shortage of blog posts complaining about git being hard. But there is a shortage of effective, popular competitors. I think that, actually, many-chefs many-branch differential version control is just a hard problem and creating a simple model for it is much harder than complaining about git.

Re: Git is too hard

#214

Post by matthiasv »

bollu wrote: post #192
anotherevan wrote: post #139

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217

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.

Re: Git is too hard

#215

Post by jeltz »

ajuc wrote: post #154
tankenmate wrote: post #107

Earlier quoted context omitted.

I would suggest it's far better to understand the data structures inherent in git and how those data structure changes are tracked and merged. Then almost all operations in git become clear. And as a side bonus it will probably make you a better coder.

How would knowing the structure (which I already do) help me remembering what was that option called?

Because most options are named after parts of the underlying structure. At least for me that makes them much easier to remember. There are some exceptions, but in general there is a logical system behind the naming.

Re: Git is too hard

#216

Post by fphilipe »

secondcoming wrote: post #130
ramraj07 wrote: post #38

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

+1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git checkout For everything else there's StackOverflow, but the info in there comes with the risk of being stale. -------------- Edit commit abaeb3b4: Add missing commands and improve formatting Edit commit 842babda: Add git checkout

I use git-show a lot to look at individual commits. Would add that to the list.

Re: Git is too hard

#217

Post by thrwyoilarticle »

3np wrote: post #175
jasode wrote: post #144

Earlier quoted context omitted.

>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file forma…

Maybe what we really need is not a new VCS, just a new CLI frontend for git.

If it was easy to create a frontend that worked seemlessly on a git repo then it would have been done already.

Re: Git is too hard

#218

Post by thrwyoilarticle »

rmtech wrote: post #194
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…

Yeah this is incorrect. One of the reasons that we able to achieve so much with computers is that there is a separation of concerns between different areas. Requiring everyone to fully understand git is like requiring people who code in high-level languages to understand and apply chip design in their day-to-day work. Imagine if when you tested some Python or Java code you got an error from your CPU and needed to tak…

>I could say more about what you would do to make a better version but a comment isn't the place for that.

I'd be very interested because it's rare for me to see anyone attempt and, when I do, they break a basic use case.

Re: Git is too hard

#219

Post by protonfish »

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

I think that's unfair because I don't see that git even has a UI - it's designed to be a command-line API. The thousands of terrible GUIs out there are so bad that using the command line directly is still the best UI. (I think GitHub has done a great job managing remote repos - I am only talking about local tools.)

Re: Git is too hard

#220

Post by drran »

ajuc wrote: post #168
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…

Imagine SQL databases worked exactly like they do now under the hood, but instead of current SELECT/UPDATE/INSERT/DELETE they used like 15 different commands with at least 4 switches each. So instead of SELECT you'd have FETCH, PULL, CHECKOUT, CLONE, READ, PEEK, and OBSERVE. And each of them could in some cases also modify or even delete the data depending on the switches. Imagine there was no division between DML an…

In distributed databases, with support for merges and conflict resolution, we have these commands. :-/
Post reply on HN