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

421–430 of 821 posts

Re: Git is too hard

#421

Post by Lendal »

thrwyoilarticle wrote: post #213
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 interac…

Not just Github. Having any GUI be your first interaction with Git is a disaster. Right now the only way to learn Git is via book or man page, and command line. All the decent GUIs I have used assume you already know Git. They are great and powerful, but they don't help at all with the onboarding process. If you know of one, please share. I had to stop using GUIs completely and learn with Git command line. Then the GUIs made sense.

Re: Git is too hard

#422

Post by rmtech »

thrwyoilarticle wrote: post #383
rmtech wrote: post #347

Earlier quoted context omitted.

Github already has centralised protections to do with who can and cannot do various things, and so do other similar systems like gitlab. So nothing is really gained but not allowing this, but it makes git very user-hostile because mistakes cannot easily be undone.

Github isn't git

That doesn't matter, the way people actually use git is that almost all repositories have someone or some small group who rule them, so nothing is really lost by having an easy option to purge things from history. And an inconvenient option (possibly more than one!) does exist.

Re: Git is too hard

#423

Post by couchand »

magicalhippo wrote: post #336
leobakerhytch wrote: post #172

Earlier quoted context omitted.

I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? All sorts of workflows become substantially more difficult (if not impossible) with kitchen sink commits. Undoing a single-line change, for instance. I dislike large pull requests, let alone commits that introduce a half dozen different changes. Sure, if you’re really…

> porcelain without it encourage overly large commits? Not for me. When using Mercurial back in the day I would manually split up commit, usually by copying over sets of files into a clean repo and committing there. In Git tho the staging area is a lie. It encourages you commit half-truths. What I'd really want is to be able to enter a commit mode where the on-disk and staging area roles are flipped. I want the stuff…

You can do the same with git stash, but it's also inadvisable because of how easy it is to lose changes. My workflow in this case is to checkout a new branch and commit the work-in-progress there, then switch back to the previous branch to check the commit. I've seen numerous pre-push scripts that do exactly that.

I wish git didn't use the disk at all! It gets in the way of parallelizing work. For instance, I'd love to be able to make a bunch of trial commits, then in parallel verify that none of them breaks the build. Or while a build/test loop is happening on one branch, switch to another to continue working.

Re: Git is too hard

#424

Post by snarfy »

Whenever posts like this come up, the amount of controversy they always generate I take as proof of git's difficulty. If git were easy, it wouldn't need to be constantly defended by supporters.

Re: Git is too hard

#425

Post by pugworthy »

dboreham wrote: post #327
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.…

It's not just the UX. It's the concepts the user has to understand in order to use git (without shooting their feet off or consulting a guru frequently).

If you use UX purely from the concept of User Experience, then failing to understanding the concept of something is a failure of UX.

That said, sometimes when you are frustrated by having to add special cases to your code, it's not your fault, it's because you're modelling a badly designed system in the first place.

Re: Git is too hard

#426

Post by fuball63 »

rossdavidh wrote: post #410

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long d…

What do you recommend in these cases? People in non-technical fields often ask me about collaborative software, "like google docs, but for non text files". My mind goes straight to VCS, but git is too hard to get them quickly up and running.

I tried SVN one time, which is a little simpler, but still didn't catch on with the person I was showing it to.

Re: Git is too hard

#427

Post by couchand »

thrwyoilarticle wrote: post #217
3np wrote: post #175

Earlier quoted context omitted.

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.

It has been. There are numerous such projects; gitless comes to mind since somebody else brought it up in a comment here.

Re: Git is too hard

#428

Post by einpoklum »

rossdavidh wrote: post #410

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But... Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long d…

If you

    rm -r some_common_dir/
or

    echo foo > important_file.txt
that would also be perceived as your fault. And yet, command shells are pretty good software.

As for non-devs editing the same document - unless that document is text (which typically it isn't for non-devs), I would probably not use git on them either.

Re: Git is too hard

#429

Post by wpietri »

thrwyoilarticle wrote: post #213
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 interac…

> You might as well ask how to unsend an email.

That is also a reasonable request.

I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people.

With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. If you FedEx the envelope, you can cancel before delivery. With a university's mail system, you can get the receiving department's admin to return something even later in the chain. And of course, you can always tell a recipient, "Hey, I sent you the wrong box, just send that back."

The reason email doesn't support unsending is not some essential property of messaging. It's just that at the time our email protocol was defined, both our hardware and software was pretty primitive, so we locked in a very primitive model of messaging. But note that more modern systems, like Slack and Facebook Messenger, happily let you unsend things. And consequently, they're effectively replacing email for most users.

Re: Git is too hard

#430

Post by peterangular »

No it's not.

If you're a dev/SWE you should be able to grok a semi-complex CLI API to control software... but the further the world gets into "everything as UIX" and "everything has to be 'easy'" the more we stray from incredibly powerful, immediately available CLI tooling.

I know of too many highly-paid people who literally refuse to learn the CLI `git` or `docker` and limit themselves/skillsets by doing everything through the comfort of a UI. To me, it's a mark of laziness.

Git isn't "too hard"... it solves an incredibly complex problem. It has a lot of capability and complexity under the hood to deal with all of the craziness of distributed development paradigm.

Post reply on HN