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

321–330 of 821 posts

Re: Git is too hard

#321

Post by secondcoming »

sethammons wrote: post #224
h0l0cube wrote: post #182

Earlier quoted context omitted.

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

We're the exact same except for the squashed merge (which I have no real objection to doing)

Re: Git is too hard

#322

Post by hvidgaard »

jorams wrote: post #271
mcintyre1994 wrote: post #114

Earlier quoted context omitted.

I have a horrible feeling your answer to this is going to stress me out, but does that work even without a force push?

Yes, --mirror implies a level of force. The man page contains this: "...locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end..."

That breaks a very simple rule that a VCS tools should adhere consistently. Do not make destructive changes unless explicitly told to. Since most other commands to not allow you to do this without -f, the same should apply here.

Re: Git is too hard

#323

Post by prepend »

oftenwrong wrote: post #266

I have often thought about what a truly intuitive, simple, easy, user-friendly VCS would look like. Git is fine for programmers, but what about non-programmers, or student-programmers? Would it be possible to make a VCS that my mother could use without sacrificing too much power? One thing I would give up easily is decentralisation - a centralised model is more straightforward, and, for better or for worse, most peop…

I’ve tried describing merging and branching to non-programmers a few times. I try not to.

I think of git as a filtering function. It’s hard but changing stuff is dangerous. So I figure making people spend a few minutes googling to be able to do something isn’t so bad.

That being said, it’s used by more non programmers than any other tool.

Re: Git is too hard

#324

Post by [deleted] »

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…

[deleted]

Re: Git is too hard

#325

Post by lttlrck »

jariel wrote: post #148
secondcoming wrote: post #130

Earlier quoted context omitted.

+1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git checkout For everything else there's StackOverflow, but the info in there comes with the risk of being stale. -------------- Edit commit abaeb3b4: Add missing commands and improve formatting Edit commit 842babda: Add git checkout

So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios. And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for t…

Stack exchange has multiple answers for most questions. It's not a useful metric; the domain is inherently complex. git has warts, like c++, go, react, npm, rust and all their cousins.

It comes with the territory. We're dealing with tools borne into world where they are, more and more, expected to be suitable for any purpose. Tough mandate, and not the tools fault.

One day git will be supplanted with something that has a different set of issues. Progress.

Re: Git is too hard

#326

Post by bovermyer »

How to use git is difficult to teach to people who are not familiar with version control. I think sometimes this community forgets that version control is not common knowledge outside of the tech sphere.

A graphical client like Sublime Merge makes it easier, but not easy.

Re: Git is too hard

#327

Post by dboreham »

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

Re: Git is too hard

#328

Post by [deleted] »

detaro wrote: post #262
thaumasiotes wrote: post #254

Earlier quoted context omitted.

You really believe that git stores -- in full -- every version of a tracked file? Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space gone?

The git book explains the internals very well, so you can easily verify it for yourself. Files are referenced as objects in trees, which are pointed to by commits. editing a file creates a new object for it. (edited for tone)

[deleted]

Re: Git is too hard

#329

Post by matthiasv »

kadoban wrote: post #268
matthiasv wrote: post #214

Earlier quoted context omitted.

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 itself requires you be able to think of it as both models, diffs and snapshots. For example most uses of `git rebase` are clearer if your mental model while doing so are of diffs. That only one is how it's implemented is besides the point really, until you get _quite_ low level.

Of course when working with Git it makes sense to think in changesets. But OP was specifically modelling the technical side starting with "We have files, which are inert objects …".

Re: Git is too hard

#330

Post by lsaferite »

ramraj07 wrote: post #95
ghayes wrote: post #85

Earlier quoted context omitted.

I'm not sure I follow your logic: why not take a few days to learn the fundamentals of git? I did that a few years back (and I'm not saying I read the source code, just learned about the base concepts from a few blogs and played around with some more advanced commands), and it has paid dividends _every single day for the last several years_. For example, I avoid tracking branches and have started using `git fetch`, `…

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

Your insistence in purposefully not understanding how to use a tool in your toolbox is frankly saddening. It's literally part of your job. You interact with it presumably daily, yet you have no clue how to be effective with that tool. And you say others are annoying for learning how to use their tools.
Post reply on HN