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

341–350 of 821 posts

Re: Git is too hard

#341

Post by jrochkind1 »

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…

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 should, and try to educate people in a completely distributed workflow if you want, I suppose. That's not about github really.

Re: Git is too hard

#342

Post by gpderetta »

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…

Agree with you. A GUI is fine (and a good thing) as long as it is just for convenience and discoverability, and it doesn't abstract git away, hide its power or try to impose its own workflow.

IMHO, a good git GUI would show exactly what commands are being run (so it is useful as a learning tool) and their result and allow it being used along side the cli.

I use magit extensively and it has all these properties.

Re: Git is too hard

#343

Post by larzang »

thrwyoilarticle wrote: post #265
outsomnia wrote: post #234

Earlier quoted context omitted.

Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree with pull and don't know what fetch is. With history if you make a vcs mistake, or realize iteratively after pushing that corrections are needed, your worthless threshing around trying to fix it becomes part of your project log forever, instead of just pushing the…

I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. I see that as a fundamental difference in how the problem space is viewed and that they're stuck with a Github-first point-of-view. To me, even with merge commits, the history s…

Completely agree, a change is an atomic change and should be contained in a single commit, I don't need to know the sub-steps it took to arrive at the final solution when I'm trying to blame or log the reason it changed 6 months from now. It also encourages bad commit messages which further confuse change history and motivation when you're creating separate commits just to fix formatting and such in your real change.

Re: Git is too hard

#344

Post by KingOfCoders »

I've used and introduced as CTO hg in the past because I think it's easier to understand. less confusing and there are extensions for many (special) use cases. Every org dropped it and I've dropped it more than five years ago because every example on the internet uses git, no one wanted to learn hg and that friction was higher than the benefit of hg to me and orgs.

Re: Git is too hard

#345

Post by [deleted] »

x87678r wrote: post #247
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.…

Wait what? How come nobody told me about gitk.

[deleted]

Re: Git is too hard

#346

Post by jrochkind1 »

With most software in general, we usually think the very definition of "easy to use" is "a high portion of users and potential users find it easy to use."

Somehow with git, lots and lots of developers (and non-developers too, but let's just consider developers) can show up and say "i've been writing code for years, i've been using git for years, I get by, but I find it pretty confusing and hard to use," and still have people saying "no, you're all wrong, it IS easy to use."

Like, how is that even logically possible? To insist that software really is easy to use even when a large number of people don't find it easy to use, is an interesting metaphysical stance.

Re: Git is too hard

#347

Post by rmtech »

thrwyoilarticle wrote: post #284
rmtech wrote: post #252

Earlier quoted context omitted.

Probably the biggest problem with the git interface is that the interface exposed to the user isn't sufficiently abstracted from the implementation. Insanely complicated commands to undo things are one symptom of this. As a user, you want to "save" some code and you also want to "share" it with others. You also want a historical record of what you did. But obviously you will occasionally save and share things you did…

Then you'd need centralised protections to decide who can delete and you instantly lose the distributed features. If I'm a user and I want to save, I do it with my text editor. If I want to share, I can do it with Github, Gerrit, Gitlab, email, pigeon. I never email people things I didn't mean to and, if I did, I wouldn't expect my email software to let me delete it. The centralised services allow it to some degree b…

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.

Re: Git is too hard

#348

Post by Supermancho »

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.

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

Re: Git is too hard

#349

Post by studius »

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.

Explain why.

Within our lifetimes, an interaction most users have with a computer could be just thinking about something to cause an action. I don't want to have to see a GUI in my brain to do that. Similarly, not everyone likes having to use what is traditionally called a GUI.

For git, I prefer the CLI, though I use some helpers for completion, I have some scripts I wrote to show remote and local branches with their authors in different states of merge, etc. My guess is that in your GUI, you don't have that level of customization, and probably didn't even think it was an option. That's the problem with GUIs for me.

Re: Git is too hard

#350

Post by lsaferite »

rmtech wrote: post #335
lsaferite wrote: post #319

Earlier quoted context omitted.

You mostly lost me at "point-and-click", but I'll bite. git rebase -i {hash before your changes} git push -f And since you talked about point and click, you could easily enough use github permissions on branches to prevent this on protected branches or you could configure your git repo to disallow force pushes. To get specific branch protections on a normal git repo you would need to use a hook to validate the update…

That only works in some circumstances. For example, suppose I init a new repo and accidentally commit my entire virtual environment, then push, then do some real work, push a few times more and then a colleague notices (after they have pulled, worked on and pushed) that the venv stuff is there. In an ideal VCS, you would have a simple command like git purge /badfolder that would make it as if it never existed. But AF…

Well, first I'd argue that you are misusing the tool if you managed to commit a large chunk of unrelated code, but that's another story.

Second, I would tell you that git has a command for just your situation.

   git filter-branch
https://git-scm.com/docs/git-filter-branch

You can run a command against every commit and it will then recommit. That would let you remove, for instance, an entire subdirectory. The downside here being that you are rewriting history on something you've shared with the world and that has larger potentials for causing issues with contributors.

I guess my point is really this, git is simply one of the many tools you likely have to use on a daily basis. If you have to use a tool in your daily job it's in your interest to really grok the various ways your tool can be used. You'll want to really understand the primary use cases in detail and the less used ones you'll want to know in passing at least. That allows you to realize that something is possible with the tool, even if you don't recall the exact specifics. A machinist would have the Machinery's Handbook, a programmer will have multiple internet references. Maybe the real point is that it's _ok_ to not know the exact syntax and need to reference it for more esoteric operations.

Post reply on HN