[yunohn]

This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”.

Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git.

The goal of being a programmer is to produce cool things, not to duel with your tooling.

[bspammer]

The irony with git is that the underlying data model is far simpler than the user interface implies. People assume git is complicated because the user interface is complicated, but it really is very simple under the hood.

So much so that you can write your own basic version of git in a couple of hours: https://wyag.thb.lt/

[vasergen]

Thanks for the link, really interesting

[SAI_Peregrinus]

The problem is that git leaks the underlying data model all over the place, even where it's unnecessary to actually controlling versions. It's a nice data model, but the user view shouldn't expose it. The data model is an implementation detail, but git treats it like a show & tell.

[sofal]

You have it exactly backwards, and I think it gets to the core of why people get so unnecessarily confused about git. The underlying data model is both much simpler than the interface and crucial to understand. If you treat git as a collection of memorized command recipes the same way you did with SVN or CVS, you're going to have a bad time. The underlying DAG needs to be top of mind when interacting with git, as it best represents the inherent complexity of the problem that code repositories are meant to solve.

[lanstin]

But this isn’t a problem because the underlying data model is almost perfect for version control of text files. In some cases the data model is an implementation detail but in this case the porcelain is the fungible detail that can change depending on surface things like people's preferences.

[thecupisblue]

I don't know git from scratch, never written it or dived into source code itself.

Yes, you can write C without understanding poinnters, you can paint without understanding colors and how they mix, draw without knowing difference between 3H and 2B, use a drill without knowing which type of head is for what.

But try doing it long term and you either gotta learn those things or your output will be limited and clear expression of your vision will be harder.

I'm not advocating for people to learn git from scratch.

I'm advocating for understanding - not low level, at least high level.

And is it better to go through a "how to use X tool in Y GUI" tutorial or how to use "X tool" and then gain immediate understanding of what Y does? What if you switch GUI's? Which knowledge will be sticking?

[wpietri]

C is a great example here. If you write a lot of C, you really have to understand pointers very well. And quite a lot else. That makes it a bad tool for many purposes, so most developers do not use it, and fewer use it every year. It's just a bad tool for modern purposes.

The same applies to the git CLI. And really, to git. The right tool for a small group C-using kernel developers 15 years ago may not be the right tool for different people doing different things today. Let's hope it goes the way of C.

[Espressosaurus]

Except you don't need to know the git CLI except when you've screwed something up. Even the reflog is available via TortoiseHg. Bisect okay maybe you have to drop to the command line, but otherwise there's no reason to futz about it when you can checkout, merge, rebase, cherry-pick, create new tags, etc. using the GUI.

My experience is that knowing the DAG in GIT is equivalent to needing to know pointers to write effective C.

Knowing the internals is more like needing to know assembly in C. Yes, it can be really useful for debugging certain classes of problems, but not really necessary in day-to-day work.

I've used git professionally for 4 years now and haven't once run into a corrupted repo or a problem googling for help couldn't solve. Day to day driver is TortoiseGit, which is frankly just a shitty TortoiseSVN skin on top of git. But I like being able to visually see the graph since at the end of the day I'm doing graph operations when manipulating the repo.

[yunohn]

> I'm advocating for understanding - not low level, at least high level.

It sounds a lot like you mean low-level, not high-level, though?

There’s more than enough to be achieved by just knowing the tree concept of git, and using a GUI to visualize it while running the basics - checkout, commit, branch, rebase, etc.

[thecupisblue]

>There’s more than enough to be achieved by just knowing the tree concept of git, and using a GUI to visualize it while running the basics - checkout, commit, branch, rebase, etc.

Oh, that's exactly what I meant. At least basic, high level understanding of the git model and basic operations on it. But most people never even get to rebasing or try do understand what lies behind magical buttons in the GUI.