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

391–400 of 821 posts

Re: Git is too hard

#391

Post by sumtechguy »

dimgl wrote: post #6

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…

Having used a few of these version controls over the years each one has its kind of 'core' strength. Most of them evolved next to each other and borrowed the shorthand of each other and copied each others API/GUI/CLI (mostly), and the shorthand of a physical library. git on the other hand stands alone in its interface. in many source controls 'checkout' for example means I get exclusive control of this file on this branch. Where as in git it does not mean that at all. That is where much of the misunderstanding comes in for git. The commands are kind of the same names but do very different things.

Re: Git is too hard

#392

Post by HelloNurse »

swiley wrote: post #292
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 would completely disagree with this, anything that adds layers between you and git creates more opportunities for misunderstanding and corner cases. Resisting a feature branch/merge workflow is what's a bad idea.

For Git clients in particular, there's the issue of GUI applications that think their mostly ad hoc, incomplete configuration should prevail over standard Git configuration (e.g. GitAhead is unable to use authentication tokens on Windows) or that their "opinionated" behaviour is good for everyone (e.g. try to modify a tag with SourceTree).

Re: Git is too hard

#393

Post by adrianN »

user5994461 wrote: post #307
skohan wrote: post #243

Earlier quoted context omitted.

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

>>> if I want to do something more complex If you want to do something more complex, the reasonable answer is usually to delete the directory and clone again.

I don't think I ever did that.

Re: Git is too hard

#394

Post by ufo »

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

For recent versions of git I'd suggest using "git switch" and "git restore" instead of git checkout.

It avoids much of the confusion from the checkout command, which does very different things depending on what flags you pass it. That said, this is only one git command. The rest still has plenty of room for confusion.

Re: Git is too hard

#395

Post by GnarfGnarf »

I've been programming since long before GUIs existed, and Git baffles me. We use Subversion, it's a lot simpler and does the trick.

Subversion integrates beautifully with third-party apps: Windows File Explorer (Tortoise), Qt Creator, Visual Studio, macOS (Cornerstone), Help & Manual, etc.

A GUI interface makes one more productive. I can right-click on a file or directory in Windows, and display all the change history at a glance.

Re: Git is too hard

#396

Post by IshKebab »

thrwyoilarticle wrote: post #241
IshKebab wrote: post #124

Earlier quoted context omitted.

> Git is one of those technologies where it's super important to get a good grasp of how to internals work. That's just an excuse for Git being super confusing. Does Microsoft say "it's really important when using MS Word to get a good grasp of how its internals work"? Of course not. Yes you need to get a good mental model of how Git works (basically, commits are efficient snapshots of your code), but that's not the…

Schoolchildren can write documents. They can't write software with many authors creating disparate, conflicting changes across vast space and time. Complaining that git is too hard is claiming this is easy.

The parts of it that involve Git are easy. By far the most difficult thing is resolving merge conflicts, but Git farms that out to third party software, and nobody here is talking about that.

The core idea of Git - a DAG of repo snapshots - can be explained in like 5 minutes. I could explain all of the other operations in 5 more minutes.

Maybe I should do a `Git in 10 minutes` video, but there are about a million of those already, and as I said, it wouldn't address the actual hard part of Git: the CLI.

Re: Git is too hard

#397

Post by thenoblesunfish »

The analogy with (La)TeX is strong. That's also very powerful, written by a luminary at the bottom level (Knuth as opposed to Torvalds), and with a command line user experience loathed by most. GitHub etc. are supposed to be like Overleaf. Why aren't they?

Re: Git is too hard

#398

Post by zzbzq »

thaumasiotes wrote: post #320
detaro wrote: post #301

Earlier quoted context omitted.

Which is explicitly a lower-level optimization applied to files well-suited for it and not related to the concept of a commit . A commit does not reference a diff.

Fair enough. The blob stores a diff. The commit stores a reference to... the diff. This is a division between the concept of the object and the implementation. But it's not an example of a diff-storing model failing to model git as it is; git as it is is storing diffs. If a commit references a "blob", and the "blob" that it references is, in fact, a diff, why would we say that the commit "does not reference a diff"?

Each commit consists of a structured collection of hash IDs for every file in the entire repo. The hash ID is generated by hashing the contents of the entire file. Not the diff.

The "diff" you're referring to is an implementation detail of the compression. It's not even always there; it depends on which commits are present in your clone. It's also not even the same "diff" you work with when you use git to generate or apply patches. Using the same word only leads to confusion.

Re: Git is too hard

#399

Post by HelloNurse »

naringas wrote: post #178
auggierose wrote: post #156

Earlier quoted context omitted.

What Hilbert space would that be?

I am not sure, but I think it's a Joke Hilbert space

There's also very little in a graph of changes and revisions that could be considered a manifold, which makes looking for homeomorphic endofunctors pointless.

But the first impression is strong, it's still a good joke.

Re: Git is too hard

#400

Post by jamienicol »

Supermancho wrote: post #348
jamienicol wrote: post #162

Earlier quoted context omitted.

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

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

Post reply on HN