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

381–390 of 821 posts

Re: Git is too hard

#381

Post by ivanhoe »

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 memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins.

The problem, at least for me, was the complexity of the model which makes the whole thing super scary when you've just started using it. That's where GUI tools come useful, as people are generally less scared of GUI tools - they make you feel there's less of chance of making a mistake because you put the trust in the tool to stop them doing something obviously stupid. However IME that trust is not really deserved as most of the GUI tools will just as happily let you mess up your repository...

Re: Git is too hard

#382

Post by bulatb »

kemiller2002 wrote: post #281

I have a real question (not trying to start a flame war). Truthfully, why do people think git is hard? Seriously, as programmers we do many, many things that are really hard. Things like thinking about abstract data structures, understanding concurrent processing, etc. I can understand not knowing it and how that frustrates people, but I genuinely don't understand why people are afraid to just dig in and learn git. S…

Git is hard because it has no client. It's a set of primitives for building one.

The "client" is your knowledge of its data model, mental mapping of obtusely named commands and flags to things you want to do, and ability to visualize/predict the outcome.

This isn't clear to learners because git manipulates a flowchart with a CLI—a graphical activity misrepresented and disserved by its nongraphical interface. It isn't obvious they need to do the work themselves the software could be doing for them, or that they're working at a different level of abstraction than they think.

Teaching the model first, before the commands or anything else, can prevent a lot of confusion.

Re: Git is too hard

#383

Post by thrwyoilarticle »

rmtech wrote: post #347
thrwyoilarticle wrote: post #284

Earlier quoted context omitted.

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.

Github isn't git

Re: Git is too hard

#384

Post by zests »

IshKebab wrote: post #124
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.

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

I gained a lot when I learned the internals of TeX (of LaTeX fame.) Of course I did not learn _all_ of the internals. There's no need.

Is (La)TeX super confusing? Sure. Is it what the pros use? Definitely. Also, read "The TeXBook", it is a masterpiece.

Re: Git is too hard

#385

Post by codesnik »

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"?

There're revision control systems based on diffs, but git's power (and durability) is that every commit references only blobs, which are (content addressable) files, not diffs. All the diffs used in git log presentation or git-diff command or git rebase command are computed on the fly from the two stored versions. And yes, if you commit a giant file, and then delete it in next commit it's there forever, until you remove or rewrite a history of a branch that references this file somewhere in history.

There're optimizations on the storage level, compression etc, but on logic level those are transparent

Re: Git is too hard

#386

Post by tirthapatel »

From the perspective of a tyro, I find it very difficult to catch on the terminology that git uses. There are simply too many concepts to understand and remember. For example, why is rebase so much more complicated while merging two branches seems fairly straightforward. Even after using it for quite some time, I almost always mess it up. In my opinion, git should abstract a lot of details from a regular user to make it more friendly and easier to learn.

Re: Git is too hard

#387

Post by thrwyoilarticle »

rmtech wrote: post #368
lsaferite wrote: post #350

Earlier quoted context omitted.

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.

So do interpreters, compilers, package managers, virtual environments, build systems, CI systems, test frameworks, targets, hosts. Your code doesn't exist in isolation, you need to grok how it works with the codes others have written and will write.

Re: Git is too hard

#388

Post by mumblemumble »

ivanhoe wrote: post #381
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 memorizing commands is really the problem. Learning just 8 git commands (clone, pull, checkout, checkout -b, commit, push, merge, rebase) will cover like 99% of situations average dev will ever encounter. And when you need something more exotic you usually can google it, usually in under 5 mins. The problem, at least for me, was the complexity of the model which makes the whole thing super scary when yo…

I suspect that the underlying model wouldn't be so scary, either, if the UI had not done such a stellar job of obfuscating it.

Re: Git is too hard

#389

Post by patrickthebold »

LgWoodenBadger wrote: post #290
anotherevan wrote: post #139

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217

Seems like an obvious play on "a monad is a monoid in the category of endofunctors, what's the problem?"

But the monad one is true, so this particular joke falls a bit flat since it's just nonsense. (I think...)

Re: Git is too hard

#390

Post by jraph »

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.

https://xkcd.com/1597/
Post reply on HN