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

401–410 of 821 posts

Re: Git is too hard

#401

Post by [deleted] »

Macha wrote: post #269
jariel wrote: post #117

Earlier quoted context omitted.

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.

[deleted]

Re: Git is too hard

#402

Post by mamcx »

skohan wrote: post #243
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.…

> Resisting GUI's is not a good idea. I disagree. In my personal experience, learning git took a lot of trial and error, but now whatever terminal I sit down in front of, I know exactly which commands I have to run to do what I want in git. When using a GUI, it's fine for the easy/common stuff, but if I want to do something more complex I have to figure out how to dig through the options provided by the tool to get t…

> learning git took a lot of trial and error, but now whatever terminal I sit down in front of

This insight why git, like other tools, is stupidely designed.

The "wrong" defaults and UX is the DEFAULT, and each USER must learn it.

Meaning:

UX * N Users = Wasted time and money

---

If I present you a screenshoot of a (real!) business apps with mis-aligned buttons, some put in weird places that mean different things that them are supposing by their labels, that use non-standard interactions that mix different UI paradigms, with rare color combinations (aka: vomit palette) , all in a SINGLE window (!), you think the solution is resist a better interface? Why we mock "regular" users or their enterprise providers, but somehow can't with ourselves?

I don't know why so many developers live in constant Stockholm syndrome and like it, and resist any suggestion to improve.

When anyone ask me about the tools I use (specially asked when somebody look at me using the terminal), if I liked, i say "No, this is the bad and ancient way, but we are here, stuck on this.."

Re: Git is too hard

#403

Post by IshKebab »

Cloudef wrote: post #158
IshKebab wrote: post #125

Earlier quoted context omitted.

The CLI.

What's so hard about the CLI?

Single commands do many different things, options are inconsistent, e.g. -n does one thing for one command, and a different thing for others, lots of common tasks require complex sequences of commands, etc.

It's pretty telling that there have been multiple attempts to write a saner CLI for Git.

Re: Git is too hard

#404

Post by recursive »

jamienicol wrote: post #162
ramraj07 wrote: post #95

Earlier quoted context omitted.

I am limited by time on what I can learn, every day I have five other things I'd rather spend my time learning about instead of git. The "git experts" that I know of are no more productive than me and more often than not do annoying things like rewriting commit histories after I made comments in their PRs, that I'm not convinced it's worth the day or two I need to learn it fully. In the end git is not in production,…

> do annoying things like rewriting commit histories after I made comments in their PRs That's exactly what I'd expect someone to do after I commented on their PR.

No one I work with does that. They do one of two things.

1) argue that they really don't need to change anything 2) push more commit(s)

Why would it be better to rewrite history?

Re: Git is too hard

#405

Post by wpietri »

ivanhoe wrote: post #381
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 don't think memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

I think more than one thing can be a problem. The CLI is confusing and the model is complicated. This means people can get themselves into weird, hard-to-debug situations. Or end up copy-pasting incantations in hopes of fixing problems, but instead might lose their work.

Re: Git is too hard

#406

Post by thrwyoilarticle »

jrochkind1 wrote: post #341
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…

I don't see what it's got to do with github. I had the same need, and the same confusion solving it, before I had ever used github, when I used a locally hosted git server of some kind for my team. Do you mean it's a problem only if you are "git push'ing" to a remote shared by those working on a software project? OK, maybe. Even before github, most projects I knew of using git used that method. You can suggest nobody…

They're complaining about git and the very first thing they discuss is how git interacts with a completely separate piece of software. Push doesn't have to be to Github, it can also mean sending an email. Obviously you can't undo that.

The Github-first problem is viewing git merely as an interface to Github, where the home of the work is and where all things are collected and operated on. From this it follows that git push is a fundamental operation like add or commit. And from this follow complaints that git commit isn't something that sends your changes to the One True Repo.

If you push then you should give up any expectation of control or ownership over the code that's sent over the communications protocol of choice. Purging a file is nice for you but in action would be a force-pushed rebase that you have to ask people very nicely to use instead of the initial branch. Controlling what branch other people use is completely out of scope for a local VCS.

The blog continues on to say that the distributed nature gets in the way of the mental model.:

>they have never even considered that there’s such a thing, because why would they? A branch is just a single concept in our head that is made complicated by the inherent distributed nature of Git.

And that's just the wrong model to have, inspired by understanding git through the lens of Github. If you're using git and you're unaware that you're operating on your local copy, not a shared workspace, then you can't place much stock in whatever mental model you come up with.

Re: Git is too hard

#407

Post by recursive »

jamienicol wrote: post #400
Supermancho wrote: post #348

Earlier quoted context omitted.

> ewriting commit histories after I made comments in their PRs > That's exactly what I'd expect someone to do after I commented on their PR. The vast majority of people do not. I certainly wouldn't expect someone to waste time on that.

> The vast majority of people do not. That's a very bold claim. It's certainly been the expected workflow everywhere I've worked. You might consider it a waste of time but I'd wager the resulting mess of commits from not doing so wastes far more time in the long run.

I've never worked in an environment where it was expected or used. As far as I can tell, no time has been wasted as a result. How would it cause time wasting?

Re: Git is too hard

#408

Post by Qwertious »

toopok4k3 wrote: post #309
willis936 wrote: post #291

Earlier quoted context omitted.

How is this not a shortcoming of the GUI implementation? What could a CLI do that a GUI could not?

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.

Writing a new git GUI doesn't solve the problem, since you need people to adopt it before it's widely installed as default on most OSes by default, and until then you'd probably need to learn the old interface anyway.

IIRC there have been various papers on Git's crappy UI and at least one two rewrites (of the interface). Gitless is the name of one.

Oh, I forgot the most important thingof all: integration with tooling! QtCreator has support and shortcuts for Git with its commands, but not Gitless.

Re: Git is too hard

#410

Post by rossdavidh »

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 drawn out cycle of embarrassment. No matter what happens, it was not git's fault, it was your fault.

Good software is not like that. Good software is the opposite of all of that. Git is the industry standard, and I have just accepted that we aren't going to get anything better, but whereas it might make sense for the Linux kernel dev community, it is not good software, and I suspect that it's not just the UI that's the problem.

Lots of non-devs also have the problem of wanting to have multiple people edit the same document, track changes, and occasionally merge them. I would never recommend that they use git, and I see no evidence that it is ever spreading beyond the dev community in any significant way. There's a good reason for that.

Post reply on HN