Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shit – An implementation of Git using POSIX shell

git.sr.ht

Post reply on HN
Print view View original

181–190 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#181

Post by JoeAltmaier »

TeMPOraL wrote: post #140
blub wrote: 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…

Its part of a bigger issue - source control tools have wildly different fundamental models. Moving to git from anything else will be confusing, because users jump to conclusion about what commands and operations are doing. Its different from other tools in important ways.

Re: Shit – An implementation of Git using POSIX shell

#182

Post by dredmorbius »

solarkraft wrote: post #175
dredmorbius wrote: post #80

Earlier quoted context omitted.

The amusement here being that git itself is Merkel trees ;-) (And yes, I've seen, and boosted, your Mastodon tirade, and am ... apprehensive in commenting here.)

Not many people know that these trees were invented by the German federal chancellor Angela Merkel. (they were not, this is a shitpost, they're actually called Merkle trees)

Thanks.

Damned edit window...

Re: Shit – An implementation of Git using POSIX shell

#183

Post by danShumway »

viraptor wrote: post #45
ddevault wrote: post #29

Earlier quoted context omitted.

You'll use git a hundred times a day, every day, for the rest of your career. It's easily worth the hour it'll take to learn it properly.

Sure, but I also use a mouse. I could learn how the optical mouse works. I have some guesses about it too, but never actually learned the details. But I'm a user of it - it works even if I don't understand exactly how and nobody tells me that I learned using the mouse "the wrong way" because of it.

I've watched children use a mouse for the first time, and there is definitely an internal model you needed to learn. No, you don't need to learn exactly how optics work, in the same way that you don't need to learn exactly how Git is reading from files, or how its hashing algorithm is implemented.

But you do need to understand that the mousepad doesn't correspond to points on the screen, and you have to learn to treat it more like a treadmill than anything else. Going back in time and thinking about it from a rollerball perspective can help with that -- new users have a tendency to use something like 90% more space because they don't grok that for long movements they have to pick up the mouse.

People are bringing up the mouse as simple because they're used to using mice. But hand anyone a mouse for the first time and you'll find out that they aren't simple. They're just doing comparatively less than Git, so the problem space is slightly easier to tackle. And that's even ignoring the hand-eye coordination problem we take for granted, and that can take weeks for someone new to computers to get over.

Talking about internal mechanics is broadly useful when teaching computer literacy -- everything from mice, to copy/cut-paste, to shift-selection of files, to the file browser itself benefits from trying to build a systemic, mental model of some kind of behind-the-scenes abstraction.

Re: Shit – An implementation of Git using POSIX shell

#184

Post by rollcat »

solarkraft wrote: post #176
viraptor wrote: post #162

Earlier quoted context omitted.

Not sure what you mean by false advertisement. Australia-Netherlands (common European pop) connection is often >300ms from a home connection. Home in Australia to Sydney pop is likely <10ms. It makes a massive difference with many small resources, or restarted transfers. That's just physics at some point.

But does it really? I can see why a large company wants to squeeze milliseconds out of asset delivery, but as a watcher of a small independent creator I would have no problem waiting a second for the video to start playing.

Background: I run a live streaming start-up.

Latency directly impacts bandwidth, which impacts quality, since all current-gen user-facing live streaming protocols that matter (HLS, DASH) are layered on top of HTTP (on top of TCP), and that's already the best trade-off for end-user delivery today.

For VOD it's less of an issue since you can just maintain a larger buffer, but with live that's a trade-off with being closer to the live edge or choosing poorer quality. It works OK for some cases, it's bad for others (like sports, or when letters on the screen become illegible due to compression artifacts).

Building your own CDN off of el cheapo VPSs is theoretically viable, the beauty of HLS and DASH is they're 100% plain old HTTP, so just drop Varnish, add GeoDNS on route53 and off you go. Actually I'd love to have the time to try that :)

Re: Shit – An implementation of Git using POSIX shell

#186

Post by jschwartzi »

im3w1l wrote: post #43
ddevault wrote: post #29

Earlier quoted context omitted.

You'll use git a hundred times a day, every day, for the rest of your career. It's easily worth the hour it'll take to learn it properly.

It's not a given you will use it for the rest of your career. As two examples, neither Google nor Facebook use git.

I found Mercurial to be just as capable and much easier to learn. I’m really only considering moving my team to Git as a least-common-denominator move since nobody really makes tools for Mercurial outside of Facebook. Otherwise it’s harder to learn Git and definitely it’s harder to train interns and juniors to use it.

Re: Shit – An implementation of Git using POSIX shell

#187

Post by jschwartzi »

cweagans wrote: post #108
im3w1l wrote: post #43

Earlier quoted context omitted.

It's not a given you will use it for the rest of your career. As two examples, neither Google nor Facebook use git.

shrug I'm probably never going to work at either of those places. For pretty much everywhere else, Git works just fine. Maybe if I play my cards right, I'll use git for the rest of my career. If not, maybe there will be something new eventually, but I imagine that the concepts learned in mastering Git would still be useful.

You should give Mercurial a try. When you enable the changeset editing extensions it does everything Git does and is much easier to use and understand. I’ve trained people on both systems and Mercurial is much less creaky. The only reason everyone uses Git is for historical reasons because most of the modules In referring to weren’t added to Mercurial until like 09 when Git started seeing widespread use.

Re: Shit – An implementation of Git using POSIX shell

#188

Post by rovr138 »

majewsky wrote: post #165
reagent_finder wrote: post #123

Earlier quoted context omitted.

...yes, remote tracking branches are interesting as well, I don't know a situation where they wouldn't be. There's plenty of weirdness in Git, but honestly my main complaint is that the interface is awful and the documentation makes Dostoyevski look modern and sleek.

You clearly have not ever worked on repos where nobody ever cleans up after themselves as far as feature branches go. I'm working with repos with remote branches numbering in the hundreds. `git branch -a` is pretty useless at this point unless paired with grep.

this is what I have my alias set to - `git branch -a --sort=-committerdate`

Re: Shit – An implementation of Git using POSIX shell

#189

Post by huherto »

JoeAltmaier wrote: post #181
TeMPOraL wrote: post #140

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…

Its part of a bigger issue - source control tools have wildly different fundamental models. Moving to git from anything else will be confusing, because users jump to conclusion about what commands and operations are doing. Its different from other tools in important ways.

I moved from SCCS to RCS to CVS to Subversion to Git.

Moving to Git was the more difficult step for me. I prefer it now. For a while I had to move back to Subversion and I hated it.

Re: Shit – An implementation of Git using POSIX shell

#190

Post by doubleunplussed »

deathanatos wrote: post #69
ddevault wrote: post #39

Earlier quoted context omitted.

I wanted to have the staging area, and I had decided upfront that I wouldn't make the repository state inconsistent between shit and git. So the index needed to be done. Also, you need to generate a tree out of something. Could just hash the entire worktree every time, but that would be pretty lame.

What I never fully understood is why the staging area isn't simply a commit that gets amended repeatedly as files are staged into it. Maybe just a tree pointer, since the rest of the commit data isn't available until commit, but you could fill in some placeholders. ("(staging)" for the message, current times for the timestamps, etc.) (Note that index doubles for other functions like merging/conflict resolution, but I…

Wow, I just totally assumed the index was a tree object. It seems much less elegant that it isn't.

Maybe it isn't because it would necessitate creating a lot of blob objects as you staged and unstaged changes, which might not get garbage collected for some time. I can't see any other reason.

Post reply on HN