Live data from Hacker News

Git is too hard

changelog.com

771–780 of 821 posts

Re: Git is too hard

#771

Earlier quoted context omitted.

> I have to laugh when you say its replacing email. Laugh all you like, but kids and the interns I've chatted with see email as something akin to how I feel about fax machines: not something they'd use by choice, but necessary for historical reasons. When I've been at organizations during a Slack adoption, email volume drops hugely; 50-80%, I'd guess. I've closed most of the mailing lists I used to run because they s…

I have no problem with using Slack or Hangouts or Discord or some other chat solution while at work. I also tend to use discord/steam for throw-away conversation with friends. At no point did I appeal to authority or history in my argument above, so drop the shit around > "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices." --- If you think Chat apps are winning, let me know when…

> If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.

You can do pretty much anything you want in WeChat, and you don't need an email.

Re: Git is too hard

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

So basically Subversion?

Re: Git is too hard

#773

Earlier quoted context omitted.

It's ok, I'm not really convinced the poster above you actually understands how distributed systems work. They seem entirely stuck in the assumption that there's a more powerful entity in the relationship that can arbitrate interactions between individuals.

Technically, I think their problem is assuming that it's acceptable for there to be such a entity, not that one necessarily exists. And then misinterpreting/misrepresenting git's semi-intentional exclusion of such a entity as a bug when in fact it's a feature.

They don't think it's a bug, they think it's something that is desirable (and git might not be the right tool for the job)

Re: Git is too hard

#774

Earlier quoted context omitted.

Nothing has stopped anyone from creating this perfect GUI(or better CLI) for Git that a lot of people seem to be missing. "Show me the code". Or in this case show me the GUI. Maybe the problem is just actually hard and the Git we have is the best current solution.

> "Show me the code". Or in this case show me the GUI. Easy: https://gitup.co It makes things that are hard or cumbersome in the CLI easy and convenient. Things I always do because I'm no longer afraid of mistakes: - split commits at random points - move commits up or down the branch - squash commits up or down the branch - edit commit messages Less often: - cherry pick against current branch - delete branches (local…

MacOS only. Otherwise seems to be a dream.

Re: Git is too hard

#775
post #774

Earlier quoted context omitted.

> "Show me the code". Or in this case show me the GUI. Easy: https://gitup.co It makes things that are hard or cumbersome in the CLI easy and convenient. Things I always do because I'm no longer afraid of mistakes: - split commits at random points - move commits up or down the branch - squash commits up or down the branch - edit commit messages Less often: - cherry pick against current branch - delete branches (local…

MacOS only. Otherwise seems to be a dream.

Yup. If I ever think about switching from MacOS to a a different OS, GitUp might be the only app that will prevent me from doing that :)

Re: Git is too hard

#776
post #192

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

this is your brain on category theory

Re: Git is too hard

#777
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…

> Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes This was surprising to me, and shows how different people's experiences of git can be. My workplace switched to git from an obsolete centralized VCS earlier this year, and I could easily answer these. Something like this is probabl…

> I could easily answer these

Maybe you find it easy because you don't see the subtleties. The answer to reverting the last commit for example can't really be that simple because it depends on what the user really wants to do. Do you want to keep the changes in staging? Reset the index but keep the changes in your working copy? Or reset the files to their state at the previous commit?

Re: Git is too hard

#778
post #86
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…

The underyling concepts are fine, the problem with git for me is the inconsistent command line interface. Stuff I'm doing less often than once a month I have to check in the manual every time. And it's nothing inherently hard - stuff like removing one change from staging or cleaning up local branch to be exactly like remote. The interface just feels like stuff is arbitrarily assigned to different commands :)

> stuff like removing one change from staging

I click on the file and click on "unstage". I don't know why people insist on using the command line for their dvcs. Is it even possible to selectively unstage or reset only a part of a file without a GUI?

Re: Git is too hard

#779

As usual, in the discussion there are a lot of folks who's advice/opinion boils down to "rtfm" and "it's not the tool, it's you!" I found working with SourceTree to be a good fit most of the time, after learning via command line for a bit. It keeps me from having to look stuff up, and is much nicer navigable than command line imho. My problem with such answers is not that I don't want to have to memorize git commands…

I'm sorry, but if you don't know everything about everything then you're lazy and useless and you need to get good.

When I was a lad, we used to walk 10 miles every day to school in the snow - AND ENJOY IT!

etc.

Re: Git is too hard

#780
A theme that comes out again and again in the comments here is that in a technical community, complaining that a tool could be better is a reliable signal of a dumb/lazy worker.

At the same time, many tools could actually be a lot better and if we all magically traveled 50 years into the future we would find all these better tools and see that it wasn't only the dumb/lazy people who used them - it would be everyone. For example, how many people write applications in low-level languages like assembler today? Not many - but at one point that was the only option and anyone who complained about it would be labelled as a lazy worker.

The signalling aspect of this certainly distorts the discussion, but bear this in mind:

It is simultaneously true that git is a tool with a poor interface and a bunch of warts AND every aspiring developer should do the work and learn it in detail so they can use that knowledge to signal to people that they're not lazy and/or dumb (and the lazy/dumb people - even knowing this - will not do it, so the signal works).

Post reply on HN