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

221–230 of 821 posts

Re: Git is too hard

#221

Post by acdha »

lmm wrote: post #191
m12k wrote: post #39

Git is hard because it precisely models the complexities of concurrently modifying source code on multiple computers. It explicitly models all of the concepts and operations that are relevant in that domain - branching, merging, my local changes, the server that my local branch is kept in sync with, rewriting local history, rewriting public history. Can you shoot yourself in the foot? Absolutely, because this stuff r…

Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't? If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it? Why can't I pull without fetching? Why will none of the 5 or so push configurations just do "push the current branch to the branch of the same name on the remote"? Why is there no way to…

> Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't?

What do you mean by this? It sounds like how stash already works.

> If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it?

This is how git has worked for years: you can checkout a non-conflicting branch without stashing.

> Why can't I pull without fetching?

Have you customized Git to not support this?

> Why do I have to detach from a branch before deleting it?

When does it make sense to do this? I can understand deleting a remote branch (which doesn’t require this) but deleting the current local branch doesn’t seem to make sense in any normal workflow.

Re: Git is too hard

#222

Post by hakre »

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…

"Truly understood" is close to a holy church I guess.

However it's perhaps really that too many people are thinking they need to use git because their church says so and then have to deal with the self chosen authority.

Re: Git is too hard

#223

Post by thrwyoilarticle »

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?

Software development is hard. That's why we have to spend years studying it and earn conspicuously good wages.

A basic project doesn't need git anyway.

Re: Git is too hard

#224

Post by sethammons »

h0l0cube wrote: post #182
secondcoming wrote: post #160

Earlier quoted context omitted.

Indeed, I forgot 'git status', and 'git add' I've honestly ever felt the need, or had the requirement, to look at the graph.

I've found it indispensable when tracking and integrating other peoples' branches. I wouldn't use it so much if I was working solo.

I've never worked solo. My teams tend to be around 6-8. Across a dozen teams, myself and nobody on the team save a couple even looked at the graph. One who loved a clean history showed it off, people thought it was pretty, and went back to work as normal. `git commit -am 'slightly helpful message' && git push origin $branch` does about 90%+ of what I've needed. When we merge the branch, squash merge works fine. History graphs, I've never felt the need for them.

Re: Git is too hard

#225

Post by eloisius »

dijit wrote: post #211
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.

I’ve had to use perforce before and was not a fan. Granted, I didn’t have to use it full time and can’t claim to be an expert, but I hated the notion of locking files, change lists, yuck. All of it felt so clunky compared to git.

Re: Git is too hard

#226

Post by [deleted] »

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

[deleted]

Re: Git is too hard

#227

Post by vijucat »

I briefly looked at Plastic SCM and really liked it (https://www.plasticscm.com/). It's design is much more sensible from the get go, and it has a great UX + UI. If things being Open Source is so important, then I dream about a world where gitlab acquired Plastic SCM and makes it open source!

I hate git with a passion and am very happy with svn. Even my business users can learn and use TortoiseSVN in one session.

Re: Git is too hard

#228

Post by alkonaut »

Agree. The argument “well this is a hard domain so tools will be complicated” I don’t buy at all.

The complexity is mostly accidental and down to poor UX choices and legacy.

As an example: why is the centralized binary storage system (LFS) using http when git isn’t? The answer: because it’s not really part of git. Congratulations, you now have two sets of auth and network issues instead of one.

Git is design damage by Unix philosophy. It does one thing and lets programs interact via command line. The problem with that for a tool that humans use is people want consistent simple UX, not unchanging UX. Scripts want unchanging UX, don’t care about consistency or simplicity.

Git is simply too low level for most users. As an example, it doesn’t even know which repo is the central one! It’s so low level that repos are repos. Yet few of us would consider our local repo to be equivalent to the blessed central repository and it would certainly help with many operations.

Re: Git is too hard

#229

Post by thaumasiotes »

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 is an object database and its objects are blobs, trees and commits not diffs

What do you think is the difference between a "commit" and a "diff"?

Re: Git is too hard

#230

Post by prionassembly »

I didn't see a mention of Sublime Merge, by the authors of Sublime Text. It's thoroughly good and free-as-in-nagware to try.

Git is still too hard to pretty much every non-developer workflow, and wouldn't omnipresent versioning (but not at the full filesystem level; with branches and explicit merges) change the world for the better.

Post reply on HN