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

161–170 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#161

Post by jasode »

ddevault wrote: post #22

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

>I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand.

Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git commands (the "porcelain").

Yes, I know that git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file format of BLOBs and SHAs, etc. If I were to implement a DVCS, I would inevitably end up reinventing many of the same technical architecture decisions that Linus came up with. But none of that insider knowledge really helps me remember git syntax if I haven't been using it in more than a month. Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes

The git UI and unintuitive syntax is just too hard for me to remember unless I use it every day.

In contrast... In vi or MS Word, I can effectively modify text without digging into underlying "rope data structure"[1]. In databases & SQL, I can "INSERT INTO x" without learning the "internals" of b-trees[2]. In Photoshop, I can stack layers without learning the math "plumbing" of alpha blending[3]. And yet for some reason, Git in particular needs people to learn it "inside out" more so than other tools. Not sure why Git needs this cognitive prerequisite.

[1] https://en.wikipedia.org/wiki/Rope_(data_structure)

[2] https://en.wikipedia.org/wiki/B-tree#B-tree_usage_in_databas...

[3] https://en.wikipedia.org/wiki/Alpha_compositing#Alpha_blendi...

Re: Shit – An implementation of Git using POSIX shell

#162

Post by viraptor »

Const-me wrote: post #137
viraptor wrote: post #100

Earlier quoted context omitted.

It all depends on the use-case/context. Hosting a single video with few concurrent views is cheaper to do on VPS. Hosting videos with short response time in any region, with high resiliency, etc. is likely cheaper to do on CDNs. It's not a myth. It's "general advice may not work for you".

> Hosting videos with short response time in any region Clouds are indeed selling that, but I think that's false advertisement. At least from here (western Balkans) it looks this way.

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.

Re: Shit – An implementation of Git using POSIX shell

#163

Post by cormacrelf »

jasode wrote: post #161
ddevault wrote: post #22

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

>I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git commands (the "porcelain"). Yes, I know that git is a DAG (Directed Acyclic Gr…

Unfortunately, I think you have to learn this way because everyone who came before you also did. So not only is the porcelain oriented towards this understanding, but so are people's existing repositories and workflows.

People regularly use the limited subset of git that Github permits without learning how it works internally. If only the 'edit this file' button were powerful enough to do actual work... It isn't, and that's the other problem: internals knowledge actually helps you do day-to-day versioning tasks. The reality is that one day two developers will submit PRs that conflict, and you'll have to find a way to merge them both, and knowing how rebasing works inside absolutely helps you. The analogy is more MSWord style-stacking than manipulating ropes directly, because Git does manage to completely hide some of its guts. (Object storage, compression, transfer come to mind.)

Re: Shit – An implementation of Git using POSIX shell

#164

Post by russellendicott »

mroche wrote: post #26
billconan wrote: post #11

are there any other implementations in other languages? (preferably c++). I use libgit2, but the code is a bit difficult to read and hack. I know there is a ruby book implementing from scratch. I want to understand the git internals.

The WYAG book many have referenced is pretty good. Haven’t gotten through it yet, but I’m looking to do a Go implementation. I also want create my own SCM if I have the brainpower for it to test some new workflow ideas.

Please do. The one package I've used was missing features like "commit all files" last time I used it a year ago. https://github.com/src-d/go-git

Re: Shit – An implementation of Git using POSIX shell

#165

Post by majewsky »

reagent_finder wrote: post #123
edflsafoiewq wrote: post #116

Earlier quoted context omitted.

It seems like you've made this example obtuse. `git remote` and `git branch` list the remotes and branches respectively. Adding -v makes both of these verbose. It will additionally show what each branch/remote is "pointing at". Adding -a to `git branch` shows remote tracking branches in additional to local branches. This not normally interesting so the default is to list only local branches.

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

Re: Shit – An implementation of Git using POSIX shell

#166

Post by oblio »

kragen wrote: post #71
na85 wrote: post #46

Earlier quoted context omitted.

>The conclusion I draw from this is that you can only really use Git if you understand how Git works. I say this as someone who uses git regularly, and who prefers it to all other version control systems I have tried: A tool that breaks the principle of encapsulation by forcing you to grok its internals if you are to have any hope of understanding its arcane and inconsistent usage syntax is frankly not a very good to…

> I don't understand how vim works beyond the base conceptual level How much time have you spent trying to figure out how to change the font size in Vim, rotate text 90° in Vim, recalculate a formula in Vim, or insert an image into a document you're editing in it? If the answer is “none”, you probably have a pretty deep understanding of the data model Vim manipulates, even if you aren't aware of it.

> rotate text 90° in Vim, recalculate a formula in Vim, or insert an image into a document you're editing in it

I'm not sure if I'm missing some features in Vim or you're actually pulling my leg by forcing me to notice that I know more about text than I care to admin :-)

(I'm not OP, BTW, just a random passer-by)

Re: Shit – An implementation of Git using POSIX shell

#167

Post by oblio »

edflsafoiewq wrote: post #116
na85 wrote: post #101

Earlier quoted context omitted.

I don't think it's asking to have one's hand held to complain about git's poor interface. There's no reason other than lazy design to have a tool where to show all remotes it's $ git remote -v But to show all branches it's $ git branch -a It's like it's been purposefully designed to be obtuse.

It seems like you've made this example obtuse. `git remote` and `git branch` list the remotes and branches respectively. Adding -v makes both of these verbose. It will additionally show what each branch/remote is "pointing at". Adding -a to `git branch` shows remote tracking branches in additional to local branches. This not normally interesting so the default is to list only local branches.

That's just by accident. There's plenty of obtuse git commands , strange command names, non-standardized parameters, etc.

Re: Shit – An implementation of Git using POSIX shell

#168

Post by masklinn »

viraptor wrote: post #28
ddevault wrote: post #22

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

> I feel like people learn git the wrong way Why do you think it's the wrong way? I sit somewhere in between and think that some people want to know the details and learning from inside is a good idea. But some other people want to simply be users and for the tool to get out of their way - and that's also good . So if the docs or the UX make either way hard or less effective, that's on the docs or the UX to improve.

> Why do you think it's the wrong way?

Because the porcelain is a nonsensical pile of crap on it’s own so you really can not make sense of it from the top down, it actively resist that approach.

That’s not an assertion that it’s a good thing mind, just that it’s the only one: learning git from the bottom up is much easier than top-down, and people who dislike that approach are simply hosed.

Re: Shit – An implementation of Git using POSIX shell

#169

Post by masklinn »

zbobet2012 wrote: post #30
ddevault wrote: post #22

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

I view not learning the basic concepts of how git works inside like trying to learn SQL without know what a table is. You could, but its easier if understand that basic abstractions which are its fundamental building blocks.

> I view not learning the basic concepts of how git works inside like trying to learn SQL without know what a table is.

That’s complete nonsense. A table is not a low level implementation detail of sql it’s a core feature.

And I don’t have to known how tables are represented on disk or what they store exactly to acquire a good intuition of how things work.

SQL is in and of itself an abstraction decoupled from the underlying concerns of implementation and execution. Something git’s porcelain definitely is not.

Re: Shit – An implementation of Git using POSIX shell

#170

Post by IshKebab »

downerending wrote: post #9

Amusing, but less than the title suggests (no porcelain, no reliability properties, no error checking, etc). Still, fun stuff.

Why would you expect reliability and error checking in a shell implementation of git? It's clearly a mad bit of fun.
Post reply on HN