Live data from Hacker News

Shit – An implementation of Git using POSIX shell

git.sr.ht

231–235 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#231
post #220
post #127

Earlier quoted context omitted.

If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool. Having to learn about the internals is a giveaway that the tool suffers from poor encapsulation. To me git is definitely one of those tools where one should satisfice and not learn it deeply, because it's not worth the effort. One can successfully stick to a si…

Almost everybody I've ever worked with who complained about Git has a conversation with a coworker that goes something like this: Coworker: "I really hate Git, it's so hard to understand what's going on internally." Git guy: "Did you read the documentation?" Coworker: "Nope." Git guy: "Did you read Git - book?" Coworker: "Nope." Git guy: "Did you read Scott Chacon's 'Pro Git'?" Coworker: "Nope." Git guy: "..."

That conversation already went off the tracks at "internally", since it shouldn't matter at all how it works internally. We do not learn how most things work in detail, because we wouldn't have time to live our life if we did.

In this particular case, git is a version control tool and it supports various typical operations for such tools. One should be able to learn the commands and then successfully use the tool. If that's not possible, I continue to assert that there's a problem with the tool.

Re: Shit – An implementation of Git using POSIX shell

#232
post #127

Earlier quoted context omitted.

If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool. Having to learn about the internals is a giveaway that the tool suffers from poor encapsulation. To me git is definitely one of those tools where one should satisfice and not learn it deeply, because it's not worth the effort. One can successfully stick to a si…

> If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool. Not necessarily. This may mean (and I think in this case, it does) that people are too afraid to learn about those "internals" - or should I say, the mental model behind the tool (and then some of those people write tutorials for others, perpetuating the prob…

Monkey see, monkey do would be watching someone use git and imitating them. Reading the manual or an overview of the commands and using them is how learning new tools typically works.

It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools and then move on with our professional lives, which likely revolve around writing software and not fumbling with git.

By the way, I love your conversation about Merkle trees below; it was one of the most surreal things I've read lately. :-)

Re: Shit – An implementation of Git using POSIX shell

#233
post #232

Earlier quoted context omitted.

> If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool. Not necessarily. This may mean (and I think in this case, it does) that people are too afraid to learn about those "internals" - or should I say, the mental model behind the tool (and then some of those people write tutorials for others, perpetuating the prob…

Monkey see, monkey do would be watching someone use git and imitating them. Reading the manual or an overview of the commands and using them is how learning new tools typically works. It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools and then move on with our professional lives, which likely revolve around…

> It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools

The problem revolves around the fact that, despite same name being used, git!branch != svn!branch, git!commit != svn!commit, etc. They serve related purposes - but not the same, because the concepts behind them are different. Learning a tool means learning those concepts. So in the process of learning "git commit" and "git branch", you're supposed to pick up on the "pointer to a node in a DAG" thing - otherwise you haven't learned "git commit", you've learned something else that's vaguely similar. And then you'll have difficulties when its behavior goes against your expectations.

Re: Shit – An implementation of Git using POSIX shell

#234
post #232

Earlier quoted context omitted.

Monkey see, monkey do would be watching someone use git and imitating them. Reading the manual or an overview of the commands and using them is how learning new tools typically works. It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools and then move on with our professional lives, which likely revolve around…

> It should be possible to learn the commands for creating a branch, uploading our changes or making a commit like it was/is possible for all version control tools The problem revolves around the fact that, despite same name being used, git!branch != svn!branch, git!commit != svn!commit, etc. They serve related purposes - but not the same, because the concepts behind them are different. Learning a tool means learning…

But they behave pretty darn close to SVN branches and commits and... they're also called branches and commits. It's clear why that happened - no one would have used a weird tool which turned the old concepts on their heads, so git was being taught based on comparisons with existing tools.

Now that git's very popular, the teachers have become arrogant and are claiming that our mental models for how VCS work are wrong and we should instead adapt our thinking to the git internals. In almost all other professions a confusing tool is scorned, but only developers are expected to learn how all sorts of weird contraptions work and then anyone who can't keep up is scorned instead.

git is almost 15 years old and here we have yet another attempt at clarifying how it works to the masses. Why are there so many git GUIs and tutorials and attempts to clarify how this tool works? It's a freaking VCS, not rocket science. git took something that used to be straightforward and doable by any developer and turned it into an over-complicated mess.

Now here's a question for you: why do you defend this anti-developer tool instead of siding with fellow developers?

Re: Shit – An implementation of Git using POSIX shell

#235
post #91

Earlier quoted context omitted.

>This "moving pointer" model of Git branches led me to instant enlightenment. As opposed to any other VCS? Feels like that model is the only one that works with SVN too. I struggle to see how "branch is a container of commits" is a viable model to begin with.

This is closer to how I would describe HG and SVN. Branches can be traced from start to merge, they are heavy. You know which commits came from what. In git you can lose track of what came from what branch when you start merging multiple back and forth, this does happen with svn.

Mercurial branches are different from git branches; they're topological structures that emerge when a revision gets an alternate child. They're like growing and stopping lines of development. They exist on their own, Mercurial simply allows to give them names. What git calls branches in Mercurial is called bookmarks.
Post reply on HN