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

361–370 of 821 posts

Re: Git is too hard

#361

Post by jlkuester7 »

funtkungus wrote: post #23
remirk wrote: post #4

Git is one of those technologies where it's super important to get a good grasp of how to internals work. Once you got that, it get easier to answer git questions for others or yourself, and to read the documentation or man pages, as you know what is happening. With how software devs use git, it's 100% worth it to read a good book on it.

I would also love to get some recommendation on git. I'm using the github desktop gui atm (very new to this world), but I'd like to start learning git. it is kinda intimidating.

https://github.com/FredrikNoren/ungit is one of my favorite Git tools. IMHO it is the perfect compliment to the command-line interface since it provides a nice visual model of your commit graph and branches. The graph is interactive so you can use the GUI for things like merging, rebasing, cherry-picking, etc (very nice for visualizing those changes). But at the same time, the Ungit interface mostly just stays out of your way unless you need it. It does not try to force you into a certain workflow or usage pattern.

Re: Git is too hard

#362

Post by gpderetta »

thrwyoilarticle wrote: post #223
Joeri wrote: post #165

Earlier quoted context omitted.

Everyone starts at the ground floor. What would you tell a beginner who has to figure out 20 different technologies including git to get a basic web project going? Besides, nobody is arguing git needs to be made weaker, just that it would be nice if it had a more gradual learning curve. Easy things easy, hard things possible. If you can’t see how git is hard you’ve forgotten what it is like to be a beginner.

>What would you tell a beginner who has to figure out 20 different technologies including git to get a basic web project going? Software development is hard. That's why we have to spend years studying it and earn conspicuously good wages. A basic project doesn't need git anyway.

eh, git is perfectly fine even for trivial projects.

Agree on the need for education to be a good developer though.

Re: Git is too hard

#363

Post by krageon »

Joeri wrote: post #165
krageon wrote: post #127

Earlier quoted context omitted.

> I probably could sit down for a couple of days and fully understand how git works This means it isn't hard. If you are capable of understanding algorithms of any complexity you should be able to learn how to use git (and how much of it) without treading on ground that is dangerous for you to use. All of this "it's too hard" rhetoric is infantilising or coddling people who frankly shouldn't be trusted to code anythi…

Everyone starts at the ground floor. What would you tell a beginner who has to figure out 20 different technologies including git to get a basic web project going? Besides, nobody is arguing git needs to be made weaker, just that it would be nice if it had a more gradual learning curve. Easy things easy, hard things possible. If you can’t see how git is hard you’ve forgotten what it is like to be a beginner.

I would tell them they don't need to figure out 20 different technologies. If they think they do, they've missed the point of the "basic" in "basic web project". If the 20 different technologies in your example include such basic things as an IDE and version control (evidently it includes at least the latter), I would tell them to start at the basics and learn the tools before they expect to be able to use them.

Re: Git is too hard

#364

Post by andrewla »

The author says that the problem is:

> I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it.

Fundamentally this is the problem. If this is your use case, then git is not for you. But this is not really a use case because people have not thought through the complexity of what a "merging of ideas" means.

If you want the simplest version of this, just use a google doc -- you get history, collaboration, all of that. It's a fine tool for what it does. You don't have to worry about backing up checkpoints or anything, or sending around multiple drafts for revision and comment -- all of that is directly included.

For people who need to manage versions, in order to use git you have to acknowledge that you can no longer treat your version control as an annoying little checkpointing thing that magically shares stuff, because that model ALWAYS breaks in reality; anyone who has used CVS knows this. Anyone who has had to do branching in Perforce or SVN knows this. You have to understand how it is implemented under the covers.

Fortunately, git is really really simple under the covers -- there's no deltas or change records, just an efficiently stored snapshot of the entire tree, and when you commit a change, it stores an efficient snapshot of the entire tree. The previous snapshot is still there, as are all previous snapshots.

Then it's just a matter of learning how each of git's commands map to changes to the underlying data model.

Re: Git is too hard

#365

Post by jamil7 »

I get frequent questions from other developers (not all junior) on how to fix weird messes in git they've made which is fine if you're just learning but at some point it's like seeing a developer who can't type properly, just kinda why subject yourself to so much extra work to avoid learning to use something. Yeah it's kinda hard and not very exciting but it's powerful, a part of pretty much every software related dicipline and we don't have an easier modern alternative right now. I don't get the stubborness around it.

Re: Git is too hard

#366

Post by rossmohax »

Why refs are not versioned themselves? Sometimes I miss an option to "checkout" state local git env of my somebody else I am trying to help with git.

This would also keep history of branch changes on the server side, making force pushes trivially revertable.

Re: Git is too hard

#367

Post by wegs »

rmtech wrote: post #194
krageon wrote: post #127

Earlier quoted context omitted.

> I probably could sit down for a couple of days and fully understand how git works This means it isn't hard. If you are capable of understanding algorithms of any complexity you should be able to learn how to use git (and how much of it) without treading on ground that is dangerous for you to use. All of this "it's too hard" rhetoric is infantilising or coddling people who frankly shouldn't be trusted to code anythi…

Yeah this is incorrect. One of the reasons that we able to achieve so much with computers is that there is a separation of concerns between different areas. Requiring everyone to fully understand git is like requiring people who code in high-level languages to understand and apply chip design in their day-to-day work. Imagine if when you tested some Python or Java code you got an error from your CPU and needed to tak…

There is a minimum bar for programmers I'd want to work with. Fully understanding git, for me, is part of that bar. The problem is that many programmers don't know how fundamental git is:

1) It's like understanding the basics of databases, network protocols, or compilers. It gives a lot of insight to how things work in a pretty deep and generalizable way. How do you organize data, and why are DAGs, Merkle trees, and hashes awesome? It's a beautiful case study in data engineering.

2) It's like knowing the shortcuts in your editor. It makes you more productive. If a programmer is hunt-and-pecking to type, and gets confused by shortcut keys, they'll be less productive.

Yes, I understand not all programmers will know how important it is to know this stuff, and I won't disadvantage someone who hasn't done this YET in hiring. But I would never hire the type of programmer who says "I don't need to know this." You do.

I'm sorry, but it takes a couple weekends of work to write yourself a git end-to-end from scratch. That's 0.5% of the time you put into a CS degree. If you don't have the interest, discipline, or drive to do that, there are plenty of jobs out there.

git internals are simple, but hard. Like Go. If you don't understand them, the userspace is a near-infinite pile or arcane complexity, incantations, half of which break something in counter-intuitive ways. If you do, it's a matter looking up the right command in the docs in a few minutes.

Yes, compilers, database, and other tools abstract away a lot of stuff. But if you don't understand the internals, you're likely to hurt yourself and my system in very bad ways. I don't want that on my team. My experience is good programmers are fluent one or two abstractions up and down, to not e.g. make a database query that does a full table walk, run out of stack space with a compiler that doesn't do tail recursion (and conversely, know they can use tail recursion with ones that do), etc. A tool you use every day definitely falls into the category of Stuff You Ought to Know, in a way that understanding how quantum tunneling is used in an SSD is in the category of Stuff You Don't Need to Know.

If you're hurting yourself with git, that's a good signal it's in the Stuff to Know category. And if you've wasted more than a few hours fighting git, as it sounds you have, it sounds like making a focused effort to learn it will save you time in the long term. Probably in a few months, even.

Re: Git is too hard

#368

Post by rmtech »

lsaferite wrote: post #350
rmtech wrote: post #335

Earlier quoted context omitted.

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

I use an x86 CPU every day for work and I have no idea how it works in detail, and thanks to the magic of separation of concerns I don't have to (perhaps apart from a few specific things like vecorizing instead of loops that I really do need to know about).

Git demanding a large chuck of user mindspace isn't an advantage for git, it's a signal that git is bad and needs replacing.

Re: Git is too hard

#369

Post by Faaak »

karatinversion wrote: post #333
strken wrote: post #304

Earlier quoted context omitted.

I think viewers like gitk or tig, or more powerful tools like magit/sourcetree/etc. when used purely to see your repo's history, are not only acceptable but are the quickest and most intuitive way of understanding what's going on. I'd hate to be restricted to `git show --oneline --abbrev-commit` or similar commands that don't show branches and merges.

In case you don’t know, there’s also git log --oneline --graph

tig is way more UI friendly though.

Re: Git is too hard

#370

Post by gpderetta »

lsaferite wrote: post #337
ajuc wrote: post #99

Earlier quoted context omitted.

The problem is - if you're not using some feature every month you won't remember how to do it anyway when you finally need to use it. So there's little point reading about exotic features upfront other than to know they exist. And which features are exotic depends on your workflow. It would help if git interface was consistent enough to make remembering this stuff easier. For example I never remember the exact option…

> For example I never remember the exact options for git reset because I'm using it just rarely enough to forget them when I need them again. I would argue the value is in knowing that something is possible using the `git reset` command so you know to go looking for the exact option to do what you want. And more likely you'll remember the operation if it's one you find yourself using frequently.

"Education is what is left after you have forgotten all you have learned."

-- someone or someone else. I forgot.

Post reply on HN