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

691–700 of 821 posts

Re: Git is too hard

#691

Post by jodrellblank »

rusk wrote: post #205
jodrellblank wrote: post #98

Earlier quoted context omitted.

I refer to my comment from a couple of days ago: https://news.ycombinator.com/item?id=25080013

That's just stupid. We're not talking about "users" here, we're talking about "engineers". If you can't grasp the complexity of Git, you've no business using it. You need to be working in an environment with a centralised VCS and somebody administering it. Unless you mean just VCS for yourself, in which case you could probably just use anything you liked rather than complaining about it ... And it's not manliness to…

You could have read their comment as saying that they have things they'd rather be doing than learning Git. Instead you took the position that expressing a desire for nice tools is a sign of their total incompetence at programming, that they are complaining because they cannot grasp its complexity (despite them saying "I can use Git" which suggests they can grasp its complexity). You dismissed "The Git UI directly models the Git internal model and that's just bad design", launching straight into calling them stupid and saying they need handholding, for merely wanting good design - because good design makes things easier to use, and things being easier to use is for stupid people.

You could have argued that Git is easy to use and therefore they are stupid for not being able to use it. Or that the interface modelling the internal workings is a good design. Or that Git's complexity is necessary and no simpler interface is possible. Instead you agree that it is complex and thrill about the complexity and use it as a showoff point about how it makes you superior. That's the manliness part. Not as you willfully misrepresent it "if you can't grasp complexity you really shouldn't be writing code" but "if you don't want to spend your life on the complexity of a supporting tool unrelated to the problem you really want to solve you really shouldn't be writing code".

Git is a tool in support of programming, learning Git is not the whole point. Programming involves dealing with complexity (often in the sense of simplifying complexity and hiding it away), but that doesn't mean everything has to be complex to use, and it doesn't mean that someone has to enjoy the complexity in everything to be a good programmer.

Re: Git is too hard

#692

Post by OJFord »

simiones wrote: post #640
OJFord wrote: post #598

Earlier quoted context omitted.

Autostash

Ok, so you don't need to know git stash (good) but you need to know that autostash exists and how to configure it, so you still don't get away without an extra concept. I suppose the nice part about autostash is that it's easier for someone to just give you a .gitconfig with it, and not have to teach you how to use git stash.

The `.gitconfig` and also be 'given' to you by just being checked into the project. Someone has to know that you can have per-repo configs, but not everyone. ;)

Re: Git is too hard

#693

Post by jayd16 »

wpietri wrote: post #648
jayd16 wrote: post #586

Earlier quoted context omitted.

>I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. You don't understand because you think you're fighting computers but you're actually at odds with other human's desires. If I pull your code, even if it was a mistake I don't want you to later rip the rug out from me and force me to figure out what happened from the history you dele…

That's a plausible reason, but it's definitely not what the person I was responding to said. "There are user reasons that won't work," is a very different answer than scoffing that the person asking the question just doesn't understand the underlying technology. I also don't think what you said is necessarily true. If person A has pushed and nobody else has pulled, then for most situations there's no reason to preven…

>I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.

Gitlab and Github (rightfully imo) came to this behavior. It was not random and is not the default git behavior which is to just allow the force push and all the chaos afterward. If you don't like it, mark your master branches as unprotected. However, there's clear reasons for the current defaults.

Re: Git is too hard

#694

Post by MaxBarraclough »

cesarb wrote: post #502
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?

> You really believe that git stores -- in full -- every version of a tracked file? Yes, it does. > Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space Yes, it is. "It's worth repeating that git stores every revision of an object separately in the database, addressed by the SHA checksum of its contents. There is no obvious connection between two ver…

> "automatic GC" which combines these "loose objects" into a "pack file"; and within that "pack file", it uses a binary diff (a xdelta) between similar objects to reduce the total size

Isn't it the case then that git doesn't store in full every version of a tracked file?

Re: Git is too hard

#695

Post by JeremyNT »

chokolad wrote: post #538
simiones wrote: post #447

Earlier quoted context omitted.

As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency. I…

> As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them. I usually do all the work in branches anyways, so I'll just create a quick branch and commit it there.

> I usually do all the work in branches anyways, so I'll just create a quick branch and commit it there.

I never work on a checked-out version of a branch that's currently being updated. I always check out a new branch for my work and rebase or merge off the branch others are working on.

I'm fully aware of stash, and every now and then I use it, but it's pretty infrequent. Seeing as you need to learn branching anyway it's not going to be important for every workflow.

Re: Git is too hard

#696

Post by SoSoRoCoCo »

gizmo385 wrote: post #578
SoSoRoCoCo wrote: post #570

Earlier quoted context omitted.

Reading all of these threads, I think the conclusion is: we still haven't figured out how to do revision control in an intuitive way, because it is highly nonlinear and our brains just don't work that way. There isn't a clear vocabulary for intricacies of revision control, yet. And if you can't name something clearly, you can't explain it clearly. The author's idea of putting an abstraction on top of git is the way t…

> When is the last time you wrote a CLI utility and listed all of the commands, subcommands, and options to make sure they all had a consistent look and feel? Most single-author tools do not do this. It is a consequence of developing in a vacuum. Team-based development allows other eyes to look at it and say "why is checkout used during branch in a different way then branches are checked out?". Git came from, essenti…

I know this sounds boring, but I enjoy looking at how programs manage command-line options. There are so many libraries in many languages. Some require structures so that help screens can be autogenerated. Some allow grouping of options `tar xvzf`, some don't require a dash, some have one-dash for short and two dashes for long options. Some require `=` between parameter and value, some (like mbed, npm, yarn and git) have subcommands and sub-subcommands.

It is truly fascinating the number of ways command-line parameters have been handled over the last 40 years.

I think someone on HN should write a blog post covering the history of CLI options. Wait, I bet there are 50 if I googled...

Re: Git is too hard

#697

Post by mdpm »

jkeat wrote: post #52
rjzzleep wrote: post #33

Earlier quoted context omitted.

I don't get that either. There have been people here arguing that svn and mercurial were both easier to use than git. But the moment I could import SVN to git I immediately switched to Git for everything. And Mercurial... I guess it's a matter of preference, but I personally never got the hang of it. And the fact that they had both SVN style continuous IDs AND hashes was deeply confusing to me. The only thing I did f…

If anyone is looking for a git GUI, Fork is great https://git-fork.com/

Fork is great, I paid for it happily. It's UI makes sense, radiates the right level of information, and you can use the keyboard almost exclusively. Heavily recommended.

Re: Git is too hard

#698

Post by wegs »

rmtech wrote: post #609
wegs wrote: post #367

Earlier quoted context omitted.

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…

> 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. I use an SSD every day though, as well as an LCD display and a laser in my mouse. So by this reasoning, I need to study quantum mechanics; it would only take a few weekends of focused study to understand the Sc…

With that attitude, I would never, ever, ever, hire you.

As a footnote, I would expect you to be able to understand things like SSD performance and reliability, and how it's affected by complex algorithms in the drive controller (e.g. wear leveling, garbage collection, write block size, etc.). I would also expect you to be able to understand things like how subpixel rendering works, how rendering engines coordinate within LCD refresh, or how displays advertise their parameters to computers.

You shouldn't take those as black boxes either. You do get into bugs and issues which relate there, and an experienced software engineer will have a depth of knowledge around oddball topics like that. That brings huge value.

It sounds like you're not a nerd. Why did you go into software engineering? It sounds like you're not interested in the stuff. There are lots of career tracks which don't expect people to do those sorts of deep dives, and where willful ignorance is okay. Engineering, including software engineering, just doesn't happen to be one of them. All the good software engineers I know will do dives into this stuff, and that expertise accumulates over time.

The key thing is most of us enjoy those deep dives. That's what makes the career track a good fit.

If you don't, you'll be doing the equivalent of maintaining a COBOL database on a mainframe as you get older.

For my engineers, I'm not looking for tools which are "Completely intuitive, just works™." That's Scratch. I'd advise you to code in Scratch if that's what you want. I want tools which enable people to be productive, efficient, and get stuff done at a high level of quality. If that has a learning curve, that's okay. People are coding 40 hours per week. If my programmers spend a month learning each year, and that makes them 50% more productive, they'll beat your Scratch team. That's why good programmers get paid the big bucks, and mediocre programmers can't find jobs.

Re: Git is too hard

#699

Post by CuriousCosmic »

0xffff2 wrote: post #630
CuriousCosmic wrote: post #436

Earlier quoted context omitted.

Don't forget `rebase -i`, `reflog`, and `bisect`. Rebasing is always a good skill to know for when someone inevitably commits binary files or secrets to a repo and you have to do a bit of surgery to fix it. Bisect of course isn't required knowledge but by god is it one of the most useful git commands a developer could know.

I think I've used `reflog` maybe... twice in a decade of daily git use. It's crazy to me that anyone would think that it's a daily use command. I don't even know what bisect is off the top of my head.

I don't use `reflog` often but I've found that 9/10 times you make a serious mistake in git, it ends up being the go to solution.

As for `bisect`, it's magic. It is used to binary search git commits back to X point in time. You can use it to manually go through previous commands to find what code/how long ago a bug was introduced. You can also rig it up with a test command (say a unit test that you copy out of the working tree/keep in a separate worktree) and have it automatically sift through the commits and tell you the first point where it starts to fail.

Re: Git is too hard

#700

Post by jnurmine »

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 Git has a "terrible UX". It really is no less worse or better than any random CLI program.

But yeah, I fear people have issues with Git because unfortunately they reflect upon their experiences with other SCMs (like Clearcase, SVN, RCS/CVS, whatever) and think the same terminology and concepts apply in Git and then it goes wrong.

Git is not really rocket science to use. People who find Git difficult or nonsensical should spend 4+4 hours of their weekend playing with Git while reading Pro Git. It's available for free at https://git-scm.com/book/en/v2.

Specifically, read chapters 2, 3, 5, and parts of 7.

You should intentionally skip chapter 10, more than likely you don't need it.

Keep Pro Git handy and come back when you've a specific need.

Post reply on HN